Jack Jansen wrote:
> 
> Jack Jansen <jackjansen@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.