#37270 closed defect (fixed)
rarian: Undefined symbols: operator delete operator new
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.1.2 |
Keywords: | tiger haspatch | Cc: | jeremyhu (Jeremy Huddleston Sequoia) |
Port: | rarian |
Description
I have this problem building Rarian on Tiger PPC:
:info:build /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Undefined symbols: :info:build operator delete[](void*) :info:build operator delete(void*) :info:build operator new[](unsigned long) :info:build operator new(unsigned long) :info:build collect2: ld returned 1 exit status
Attachments (2)
Change History (8)
Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
comment:1 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
comment:2 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
It seems to me the problem is that rarian-example uses librarian.dylib, and librarian.dylib was compiled using g++ and uses new and delete, and rarian-example is being compiled with gcc. I am able to get rarian-example to compile either by adding -lstdc++ to the flags, or by using g++ instead of gcc. But I don't know the best way to make the build system do either of those for us.
comment:3 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
It looks like the problem is a toolchain bug.
librarian.dylib should be linking against the C++ runtime.
rarian-example does not need to link against the C++ runtime as it is not a C++ application.
rarian-example just needs to link against librarian.dylib.
---
What happens if you use a more modern toolchain (MacPorts' apple-gcc42, ld64, cctools ports)?
comment:4 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Please install those ports then goto the work directory and try
/opt/local/bin/gcc-apple-4.2 -pipe -O2 -arch ppc -arch ppc -o .libs/rarian-example rarian-example.o -L/mp/lib ../librarian/.libs/librarian.dylib
I suspect it will link correctly.
Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Attachment: | rarian.diff added |
---|
comment:5 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | jeremyhu@… added |
---|---|
Keywords: | haspatch added |
Thanks. Yes, using apple-gcc42 does work, as in the attached patch. I'm just hesitating to commit it because adding a huge dependency is a heavier solution than adding -lstdc++ or using g++-4.2, and I don't know if adding -lstdc++ or using g++-4.2 would be equivalent or whether using apple-gcc42 offers additional benefits. Also didn't we at one point have that problem on Tiger where once you start compiling anything with apple-gcc42 / ld64 / cctools you have to compile everything that uses it with apple-gcc42 / ld64 / cctools as well?
comment:6 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | new → closed |
s/g++-4.2/g++-4.0/g
Committed the patch in r102267.
Here is the upstream bug report: https://bugs.freedesktop.org/show_bug.cgi?id=38234