Marc-Andre Lemburg <m...@egenix.com> added the comment: Jack Jansen wrote: > > Jack Jansen <jackjan...@users.sourceforge.net> added the comment: > >> Jack, could you please comment on why the LDFLAGS are added to > LDSHARED >> by configure, rather than using LDFLAGS as extra argument to LDSHARED > ? > > Because this worked, no deep reason. The initial framework builds were a > big hack, because they were neither static nor shared builds (because > the extensions were linked against the framework), so I had to find > something that worked while hoping I wouldn't break too much on other > platforms.
Well, it does break on Mac OS X (and only there) now, since for universal builds, the Mac gcc complains if you pass in the -sysroot option more than once :-) I was under the impression that the "-bundle" option was needed as last linker option and that this was the reason for adding LDFLAGS directly into LDSHARED. But if there are no deep reasons, then I'd suggest to not add LDFLAGS to LDSHARED anymore and instead just use it normally. > In case anyone is interested in my opinion: I would scratch the whole > configure/make suite and rebuild it from scratch. As others here have > noticed, the OPT/EXTRA_CFLAGS pattern that Python adhered to has lost > out the the CFLAGS/LDFLAGS pattern, and more such things. And this is > important if people want to do recursive builds. Even though we do have a flat Makefile now, there still is some recursion left: Python uses distutils to build most of the included C extension modules. Part of the patch targets exactly this recursion: LDFLAGS is currently not being passed on to the shared mod build sub-process. > But: it's a major undertaking to get this working, especially if you > don't want to pull in libtool:-( What if we just remove all the extra cruft and just use CFLAGS ? LDFLAGS is not such a mess. It just needs to be propagated to all parts of the process. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1628484> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com