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
cross-compiling).
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"
CPPFLAGS=...
elif $gcc_version="2"
CPPFLAGS=...
fi
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
gcc2.95-build.
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
__STD::string
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.
uli
Reply to: