this seems to be the same problem for xdrawchem in unstable that I can't figure out.

---

TS

http://southofheaven.org/

Chaos is the beginning and end, try dealing with the rest.


On 18-Apr-05, at 6:20 AM, David R. Morrison wrote:

Hi Martin.

I had been very puzzled by those missing symbol problems, so I'm glad you figured it out.  The timing is excellent, because we haven't pushed -fabi-version=1 into stable yet, or fully committed ourselves to the Tiger upgrade strategy which uses it.

However, this discovery leaves us completely without a strategy for the Tiger upgrade.  The only one I can imagine at the moment is to force users to run gcc_select=3.3 when running under the 10.4-transitional tree, and later having them run gcc_select=4 when switching to the 10.4 tree.  Not a great strategy; maybe somebody will come up with a better one.

  -- Dave


On Apr 18, 2005, at 5:23 AM, Martin Costabel wrote:


Please have a look at the threads

[Fink-users] unixodbc2-2.2.11-10 failed
[Fink-users] scribus compilation fails
[Fink-users] Re: inkscape fails
[Fink-beginners] Problem compiling latest version of xdrawchem
[Fink-users] coot compilation failed

from the last few days. They all have in common that ld fails with errors of the form

ld: Undefined symbols:
typeinfo for QPtrCollection

The symbols vary, they are often from libqt-mt, but also from various libgtkmm* and other dylibs. Fink is the latest, and g++ is g++-3.3.

In the case of scribus, I have verified that the problem disappears when I remove the new default -fabi-version=1 CXX flag from PkgVersion.pm.

I don't know if some other factor comes into this, but it is not OSX 10.3.9 nor the version of gcc (except gcc-4 where we have seen the same problem earlier) nor ld or dyld.

This seems to indicate that contrary to the documentation, -fabi-version=1 is not the default for g++-3.3, and that -fabi-version=1 creates binary incompatibilities. I have not yet tried (don't have the time) if recompiling the concerned dylibs with the -fabi-version=1 flag solves the problem. It wouldn't solve it actually, because this would mean that we have to recompile basically everything that involves g++. Not what the abi-version flag was intended for...

-- 
Martin


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
_______________________________________________
Fink-devel mailing list




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
_______________________________________________
Fink-devel mailing list



Reply via email to