Unusual error message from gcc34 ?

Matthew Dillon dillon at apollo.backplane.com
Sat Jul 3 22:30:37 PDT 2004


:Hi Matt,
:
: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,
:e.g. aspell.
:
: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.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>





More information about the Bugs mailing list