[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: HPPA assistance

On Sunday 16 December 2001 21:44, Jeremy T. Bouse wrote:
> Could I kindly request someone with a lil more experience to try
> and take a look at the buildd.d.o log for fwbuilder and possibly see if
> they can determine if this is a problem with the state of HPPA at this
> time or if it's a problem with source code I need to report upstream...
Hmm, it is not only fwbuilder: it is also libfwbuilder.
The most easy to fix part of it is the improper lack of std:: in numerous 
places (please don't use using namespace std in library-headers as they 
affect everyone that uses the header). 

Another part is a bit more tricky: libfwbuilder comes with a config-script 
called libfwbuilder-config. In this script is a line like this:
  CPPFLAGS="-I/usr/include -I/usr/include/g++-3"
This line has two issues: one is that the first include _must_ not be 
necessary if the compiler is probably installed. It might even break builds 
with compilers that have their standard-include-dir somewhere else (eg when 
 The other issue is the second include-dir: to that applies the same problem 
as with the first, but this one is even worse, because it only works for a 
specific compiler (g++ < 3).
 As a workaround, one might change this line to
  if $gcc_version="3"
  elif $gcc_version="2"
but this should not be necessary. I set this line to 'CPPFLAGS=""' and it 
worked for me. However, since libfwbuilder is a C++-lib, there will be other 
problems when calling libfwbuilder-config with --libs: you cant use 
g++2.95-object-code with 3.0 object-code.
 This script also produces some other paths that seem a bit dubious to me, 
maybe it is time to see which  of them are important or not.
Disclaimer: I assume that the script was also generated by some rules and not 
hand-written. So maybe this script _is_ right because it is tweaked for a 

Another issue is the way certain libfwbuilder-includes are used:
  #include "FWObject.hh"
should be
  #include <fwbuilder/FWObject.hh>
if the above mentioned script does not spit out '-I/usr/include/fwbuilder/' 
as eg SDL's sdl-config-script does. I personally would prefer to use the 
above version, not SDL's way.

I noticed that there is a '-I/usrlocal/include/fwbuilder/' in the 
command-line params, but did not examine any further where it came from.

Another point I stumbled across is some staements like
which seems to be an intended workaround for STLs that are defined in the 
global namespace.

I didn't attach the diff, since it would probably be a bit large, but if you 
want to, I can move it to a public place. However, my diffs are probably not 
what will ever move upstream because
 - I sometimes 'hacked' the libfwbuilder-headers by putting some things 
before their include-statement
 - #include <fwbuilder/...> vs #include "...". This should be decided by 
upstream. However, urge them to take the first.
 - the sources need a bit of cleaning, especially the #includes are too many 
for my taste, a well-defined forward-declaration would help a lot. Another 
issue is the compile-commands: too many redundant include-paths.
 - I never got it to build completely since that would mean starting with 
sigc++, gtkmm etc. However, that only affects the linking, not the compiling. 

OK, I will send this already although I am not yet totally through (fscking 
includes slow compile to a crawl...) but my system need downtime.


Reply to: