Issue 1034496: Configure uses GNU ld flags with non-GNU compilers/linkers (original) (raw)

Issue1034496

Created on 2004-09-25 08:52 by dschatt, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (3)
msg22551 - (view)	Author: Drew Schatt (dschatt)	Date: 2004-09-25 08:52
I was just attempting to build Python 2.3.4 on Solaris 9, using Sun's Compilers and linkers (/opt/SUNWspro/bin/cc and /usr/ccs/ bin/ld). The configure script correctly determined that I was not using either GNU gcc or GNU ld. However, it continued to put GNU specific variables into the Makefile (specifically, -Wl,). This broke several things, until I manually removed them. The first place it broke was when it created the shared library, which, because of the different ways that Sun's linker and GNU ld handle options, ended up being named "name\=libpython2.3.so.1.0" because Sun's compiler detected two -o flags (the first being in the -Wl,-soname=libpython2.3.so.1.0 -o libpython2.3.so.1.0) - and Sun's linker takes the first -o flag it sees (it helpfully tells you that, though). So... the GNU specific flags need to ONLY be used if the GNU ld/ gcc are being used.
msg22552 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2004-09-26 17:28
Logged In: YES user_id=21627 I'm a bit surprised that you are saying that the C compiler has problems with -Wl, options. Atleast in "Sun WorkShop 6 update 1 C 5.2 2000/09/11", the -Wl option is documented for cc, and works fine. Instead, it appears that the system linker does not support the -soname option. However, this option is only used if you build with --enable-shared, which apparently is supported only for GCC on Solaris. So as a work-around, don't use that option. I have now replace -shared with -h in Makefile.pre.in 1.136.6.5 and 1.148, which should fix this bug. Since I don't have SunPRO, I cannot test that scenario.
msg22553 - (view)	Author: Trent Mick (tmick)	Date: 2004-11-05 19:15
Logged In: YES user_id=34892 > I have now replace -shared with -h in Makefile.pre.in > 1.136.6.5 and 1.148, which should fix this bug. Since I > don't have SunPRO, I cannot test that scenario. Verified that this works with the Sun PRO C compiler on Solaris 2.6 and Solaris 8.