Apache OpenOffice (AOO) Bugzilla – Issue 18064
FreeBSD-4.8: python/makefile.mk uses ld which fails with -pthread
Last modified: 2003-11-23 11:45:21 UTC
The makefile.mk uses a ld to link the libraries, but ld fails to link with -pthread. The correct sollution is to use $(LINK) which points to the used gcc compiler. Unfortunately gcc doesn't understand --whole-archive and --no-whole-archive. You have to use -Wl,-whole-archive and -Wl,-no-whole-archive instead. The following patch does this for FreeBSD, but maybe this should also be done for the generic UNX case.
Created attachment 8361 [details] Patch for python/makefile.mk
Target 1.1.1
Set keyword approval_pending. Please approve!
I found another problem in python. I'm not sure why I didn't see this problem last time, but the configure.in in the python source archive needs the following patch: --- misc/build/Python-2.2.2/configure.in.orig 2002-10-10 17:26:46.000000000 +0200 +++ misc/build/Python-2.2.2/configure.in 2003-10-10 01:28:18.792328000 +0200 @@ -830,11 +830,11 @@ OpenBSD*|FreeBSD*) if [[ "`$CC -dM -E - </dev/null | grep __ELF__`" != "" ]] then - LDSHARED="cc -shared ${LDFLAGS}" + LDSHARED="$(CC) -shared ${LDFLAGS}" else LDSHARED="ld -Bshareable ${LDFLAGS}" fi;; - NetBSD*) LDSHARED="cc -shared ${LDFLAGS}";; + NetBSD*) LDSHARED="$(CC) -shared ${LDFLAGS}";; OpenUNIX*|UnixWare*) if test "$GCC" = "yes" then LDSHARED="$(CC) -shared" This has to go into the Python-2.2.2.patch, otherwise we are linking gcc 3.2 build object files with the system cc (propably gcc 2.95)
Hi, @python.diff: Sounds reasonable, I think it should be possible to apply it to the freebsd, irix and the general unix branch, this would simplify the makefile.mk a little. @configure.in: Linking 3.2 pure-c objects with 2.95 linker is probably not harmful, but I agree that it would be cleaner to do this with the correct linker. I also would like to correct this for the other platforms. I currently setup my build env for 1.1.1, this will take until Oct. 14th probably (slow internet connection). I'll then create a new patch file all platforms and attach it to this issue, so that you can verify again. Hmm, as far as I understood, we will need Sander's or Martin's approval for commit then ? Bye, Joerg
> @python.diff: Sounds reasonable, I think it should be possible to > apply it to the freebsd, irix and the general unix branch, this > would simplify the makefile.mk a little. Yep. > @configure.in: Linking 3.2 pure-c objects with 2.95 linker is > probably not harmful, but I agree that it would be cleaner to do > this with the correct linker. I also would like to correct this for > the other platforms. I already created a patch. For configure, not configure.in! And I had to use ${CC} instead of $(CC)! I used it for my FreeBSD tinderbox build, but I can not get to that machine right now. I can post the patch on Monday. > Hmm, as far as I understood, we will need Sander's or Martin's > approval for commit then ? Hmm, as it is your project I think you can approve my patches, and I guess I can approve your patches as long as they are related to build issues, or I feel they are safe. But "one of them" has to verify our patches before they are merged to the master work space. Volker
Hi, I need to prefix -soname and libpython.so.2 also with -Wl, and the additional -ldl and on linux, so we still need to have to separate link lines for both platforms, so I currently don't see an advantage in changing the general unix case. Waiting for your configure patch. Bye, Joerg
Created attachment 10256 [details] New Pyton patch, generated with dmake patch/create_patch
jbu->vq: Linux x86/windows still work fine with both patches, so go ahead and commit (I still don't have commit access for external, otherwise I would have done it)
Committed to ooo111fix1.
Closing.