DragonFly bugs List (threaded) for 2004-07
Re: Unusual error message from gcc34 ?
:This turned out to be a 'libtool' problem, which I finally remembered from
:when NetBSD-CURRENT changed compilers a while ago. It had nothing to do
:with DFly itself.
:When switching compiler versions I find that I need to re-install the
:libtool port using the new compiler.
:There are evidently some important PATH variables that get built in to
:libtool when it gets installed. It then uses those PATH variables to
:look for libraries when you compile any other port which uses libtool,
:I'm not sure why Hiten didn't run into the same problem. I can use both
:compilers to build 'aspell', but only if I re-install libtool each time I
:switch compilers in make.conf.
:Anyone know of a way around this?
:Maybe I should ask if I'm the only one who has this problem, come to
:think of it :o)
Well, since the crtbegin/end code was reorganized those object files
should now be in /usr/lib regardless of which compiler you are using.
But if some of the 'old cruft' in /usr/lib/gccX is still laying around
then a libtool build might get confused about that. Running the upgrade
target should have cleaned all that junk out.
If everything is brought up to date (you cvsup, buildworld, installworld,
and make upgrade), and you then rebuild libtool, it should no longer fail
on crtbegin/end when you switch compilers via CCVER since crtbegin/end
will no longer move.