Re: [MacPorts] #15010: kdelibs3 3.5.8 fails to build
#15010: kdelibs3 3.5.8 fails to build --------------------------------+------------------------------------------- Reporter: gargasm@gmail.com | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Resolution: | Keywords: kde kdelibs3 --------------------------------+------------------------------------------- Comment (by gargasm@gmail.com): Replying to [comment:7 ryandesign@macports.org]: thank you so much for replying to this thread! i still haven't gotten anything working, as many other things have come up in the time between.
If you're on Tiger, how were you using gcc 3, where gcc 4 is the default? Did you `gcc_select` version 3? You should not do so. This was definitely [http://lists.macosforge.org/pipermail/macports- users/2007-April/002431.html the cause] of the "dyld: Symbol not found: _sprintf$LDBLStub" message for another MacPorts user. MacPorts 1.7.0 will no longer care about what you set your default compiler to with `gcc_select`; e.g. it will always use gcc 4 on Tiger. But MacPorts 1.6.0 still cares and will use whatever you have selected, sometimes with unfortunate results if you don't have gcc 4 selected.
yes, i had in fact `gcc_select`ed gcc 3 in order to compile one piece of software for ipodlinux and forgot to change it back until a lot of the macports tree was installed. quite a stupid mistake, but it's good to know that was quite likely the root of all my troubles. so the question remains...what's the best way to fix this? just dump /opt/local and start over w/ gcc 4? upgrade to 1.7 and {{{sudo port upgrade installed}}}? seems like it might be easier to just go with the wipe.
Replying to [comment:6 gargasm@gmail.com]:
i even made sure that {{{/opt/local/[s]*bin}}} is at the head of $PATH... When building ports, MacPorts doesn't use your PATH variable, or any other environment variables you may have set. is there such a thing as an include path variable? During the configure phase, MacPorts sets the CPPFLAGS to include -I${prefix}/include and the LDFLAGS to include -L${prefix}/lib. This should be all most ports need to be able to find other ports' headers and libraries.
thanks, that is useful info, although my current skill level leaves me without the ability to use it. i suspected something like that was going on, but i don't yet know how to modify configure scripts or makefiles to change things like that. -- Ticket URL: <http://trac.macports.org/ticket/15010#comment:8> MacPorts <http://www.macports.org/> Ports system for Mac OS
participants (1)
-
MacPorts