On 04 Jan 2008, at 10:21, Dominique Dhumieres wrote:
> Updating to plplot-5.8.0-1001 failed on Intel/Leopard with:
>
> ...
> /bin/sh ../../../libtool --tag=CC --mode=link gcc -Os -fstrict-
> aliasing -Wno-long-double -L/sw/lib/python2.5/config -Wl,-x,-
> dead_strip -o cplplotcanvasmodule.la -rpath /sw/lib/python2.5/site-
> packages -Wl,-m -rpath /sw/lib/python2.5/site-packages -module -
> avoid-version ../../../src/libplplotd.la ../../../bindings/gnome2/
> lib/libplplotgnome2d.la -Wl,-framework,CoreServices,-
> framework,ApplicationServices -L/sw/lib -L/usr/X11/lib -
> lgnomeprintui-2-2 -lgnomeprint-2-2 -lgnomecanvas-2 -lxml2 -
> lart_lgpl_2 -lgtk-x11-2.0 -lgdk-x11-2.0 -lXrandr -lXinerama -lXext -
> lXfixes -lXcursor -latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lXft -
> lXrender -lpangox-1.0 -lX11 -lpangoft2-1.0 -lfontconfig -lfreetype -
> lz -lpango-1.0 -lm -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -
> liconv -L/sw/lib -lgobject-2.0 -lglib-2.0 -lintl -liconv
> cplplotcanvasmodule_la-cplplotcanvas.lo cplplotcanvasmodule_la-
> cplplotcanvasmodule.lo -lm
> gcc ${wl}-undefined ${wl}dynamic_lookup -o .libs/
> cplplotcanvasmodule.so -bundle .libs/cplplotcanvasmodule_la-
> cplplotcanvas.o .libs/cplplotcanvasmodule_la-cplplotcanvasmodule.o
> -L/sw/lib/python2.5/config ../../../src/.libs/libplplotd.dylib -L/
> sw/lib/freetype219/lib /sw/lib/freetype219/lib/libfreetype.dylib -L/
> sw/lib /sw/src/fink.build/plplot-5.8.0-1001/plplot-5.8.0/lib/
> csa/.libs/libcsirocsa.dylib /sw/src/fink.build/plplot-5.8.0-1001/
> plplot-5.8.0/lib/nn/.libs/libcsironn.dylib /usr/lib/libltdl.
> 3.1.4.dylib /usr/lib/libdl.dylib /usr/lib/libm.dylib ../../../
> bindings/gnome2/lib/.libs/libplplotgnome2d.dylib /sw/src/fink.build/
> plplot-5.8.0-1001/plplot-5.8.0/src/.libs/libplplotd.dylib -L/usr/
> X11/lib -L/usr/X11R6/lib /usr/lib/libpthread.dylib /usr/X11/lib/
> libXau.6.0.0.dylib /usr/X11/lib/libXdmcp.6.0.0.dylib /usr/lib/
> libexpat.dylib /usr/lib/libz.dylib /usr/lib/libc.dylib /sw/lib/
> libgnomeprintui-2-2.dylib /sw/lib/libgnomeprint-2-2.dylib /sw/lib/
> libgnomecanvas-2.dylib /sw/lib/libxml2.dyl
> ib /sw/lib/libart_lgpl_2.dylib /sw/lib/libgtk-x11-2.0.dylib /sw/
> lib/libgdk-x11-2.0.dylib /usr/X11/lib/libXrandr.2.0.0.dylib /usr/
> X11/lib/libXinerama.1.0.0.dylib /usr/X11/lib/libXext.6.4.0.dylib /
> usr/X11/lib/libXfixes.3.1.0.dylib /usr/X11/lib/libXcursor.
> 1.0.2.dylib /sw/lib/libatk-1.0.dylib /sw/lib/
> libgdk_pixbuf-2.0.dylib /sw/lib/libpangoxft-1.0.dylib /usr/X11/lib/
> libXft.2.1.2.dylib /usr/X11/lib/libXrender.1.3.0.dylib /sw/lib/
> libpangox-1.0.dylib /usr/X11/lib/libX11.6.2.0.dylib /sw/lib/
> libpangoft2-1.0.dylib /usr/X11/lib/libfontconfig.dylib /usr/X11/lib/
> libfreetype.dylib -lz /sw/lib/libpango-1.0.dylib /sw/lib/
> libgmodule-2.0.dylib /sw/lib/libgobject-2.0.dylib /sw/lib/
> libglib-2.0.dylib /sw/lib/libintl.dylib /sw/lib/libiconv.dylib -lm -
> Wl,-x -Wl,-dead_strip -Wl,-m -Wl,-framework -Wl,CoreServices -Wl,-
> framework -Wl,ApplicationServices
> ld64: warning: option -m is obsolete and being ignored
> ld: duplicate symbol __PyGObject_API in .libs/
> cplplotcanvasmodule_la-cplplotcanvasmodule.o and .libs/
> cplplotcanvasmodule_la-cplplotcanvas.o
>
> collect2: ld returned 1 exit status
>
Don't know how to fix this; have no access to 10.5 _nor to a 64 bit
machine at the moment
_ though I see now in man ld that "-m" is marked as 32-bit only...
The problem occurs because of a common symbol (from %p/include/
pygtk-2.0/pygobject.h);
in bindings/gnome2/python :
# nm -om *.o|fgrep _PyGObject_API
cplplotcanvasmodule_la-cplplotcanvas.o: 00000010 (common) external
__PyGObject_API
cplplotcanvasmodule_la-cplplotcanvasmodule.o: 00000010 (common)
external __PyGObject_API
gcwmodule_la-gcw.o: 00000010 (common) external __PyGObject_API
gcwmodule_la-gcwmodule.o: 00000010 (common) external __PyGObject_API
(the latter 2 files are linked together in a later link command)
With my ld, adding the '-m' flag (which is done in the patchscript),
avoided the 'duplicate symbol'
error, and led to proper linking:
# nm -m .libs/cplplotcanvasmodule.so |fgrep _PyGObject_API
000047b0 (__DATA,__common) external __PyGObject_API
What is the correct way to achieve this with ld64 (have no way to
experiment with it..) ?
The only doc I find relative to common symbols is
1) in `man ld` the items "-commons" and "-warn_commons" are marked
"64-bit only",
and suggest that common symbols are no problem...
2) In
http://developer.apple.com/documentation/DeveloperTools/Conceptual/
MachOTopics/Articles/executing_files.html#//apple_ref/doc/uid/
TP40001829-DontLinkElementID_53
"A common symbol is a symbol that may appear in multiple intermediate
object files. The static linker permits multiple common symbol
definitions with the same name in input files, and copies the one
with the largest size to the final product.
...
A multi-module shared library, which ld builds by default, cannot
have common symbols. However, you can build a shared library as a
single module with the -single_module flag."
Apart from the apparent contradiction between the second line and the
first, here it is a bundle that is linked (so no -single_module flag
is possible).
In the meantime _ i.e., till someone knowing ld64 can fix this _ you
can use plplot-nognome.
Jean-Francois Mertens
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Fink-devel mailing list
[email protected]
http://news.gmane.org/gmane.os.apple.fink.devel
