From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-12-18 20:50:40
----- Original Message -----
From: "Rene Rivera" <grafik666_at_[hidden]>
Sent: Tuesday, December 18, 2001 6:21 PM
Subject: Re: [jamboost] Question on patch
> Sorry for the delayed response, I'm in the middle of takling Win32 & cross
> memory problems :-(
> On 2001-12-18 at 03:19 PM, david.abrahams_at_[hidden] (David Abrahams) wrote:
> >Why did you comment out these lines in gcc-stlport-tools.jam?
> ># STDHDRS = ;
> ># STDLIBPATH = ;
> >The point was that whatever was given by the gcc toolset should be
> >by what we calculate in this toolset. This could be important in the case
> >stlport, since the stlport paths must precede the system-supplied paths.
> >flags rule might otherwise just tack the new STDHDRS values onto the end
> >the existing list.
> Those lines where reseting the values AFTER they where set by the
That's intentional. You just do it again the stlport toolset:
flags gcc-stlport STDHDRS : $(STLPORT_ROOT)$(SLASH)stlport
flags gcc-stlport STDHDRS : <sysinclude> ;
> Which is why I changed the GCC tools to put the includes in the system
> path "-isystem" which places them before any defaults of the compiler.
In that case, do you still want $(GCC_INCLUDE_DIRECTORY) in there?
> Unfortunately I only have GCC on Linux to test this with so I don't know
> wether this works in the other GCC installations :-( And at least for me
> Linux) the GCC_INCLUDE_DIRECTORY and GCC_STDLIB_DIRECTORY are always
Here's a test to try: install some other gcc in /usr/local/gcc-<version>.
Then set GCC_ROOT_DIRECTORY to point to that directory and try to build with
the newly-installed compiler.
> I'll try and see if I can make both of them work together, probably using
> different variable that the other tools use, like
> and STLPORT_STDLIB_DIRECTORY.
> >You added "lib" to the beginning of the library name for gcc-stlport to
> >find. I'm pretty sure that won't work, since the -l option automatically
> >prepends "lib". So there would have to be a library called
> >"liblibstlport_<version>.a". Did you test this change?
> Hmmm, don't know why I did that... I don't even remeber doing that change
> I know I changed the literal version number that was on the dynamic
> because to me it made more sense to point to the symbolic link instead of
> specific version. Which thinking about it would cause problems with
> system that don't generate the symlink during the build. So that change
> also not work on non-*nix types like Windows with GCC.
> Which begs the question, which I saw someplace else, probably in the
> better support for stlport than using the tools approach. Because as it is
> will never work for everyone :-(
Check out the Wiki material at
esign_Proposal shows a way of addressing that question. It's a bit
disorganized, but I'm going to try to consolidate everything into a single
document before the year ends.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk