python26 needs a small change in Portfile to build a true universal binary

[Veence (Vincent)]

The Portfile of lang/python26 lacks this line:

configure.args-append --with-universal-archs=all

that must be inserted as the last line in the variant universal braces (i.e. after --enable-universalsdk…)

Without this line, the build will produce only 32bit x86 or PPC binaries.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

While investigating this issue, I found that python26 was linking against /usr/lib/libz.dylib.
This was fixed in r42317.

Unfortunately, this fix makes 64 bit universals harder than just adding --with-universal-archs=all.
zlib must be changed as well.

[jmroot (Joshua Root)]

4-way universal builds won't be supported until MacPorts 1.7 is released.

[Veence (Vincent)]

This link against libz.dylib is strange:

otool -L /usr/pkg/bin/python2.6 /usr/pkg/bin/python2.6:

/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)

(I use /usr/pkg as prefix since I am used to pkgsrc on my NetBSD box at work)

On my Leopard copy, libz.dylib is a 4 arch dylib, so this is not an issue.

DYLD_LIBRARY_PATH should contain ${prefix}/lib in order to select the macports libs first. Building a universal zlib out of macports does not seem to be an issue, or am I wrong?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

libz.dylib comes into play in the binascii package:

otool -L /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/binascii.so 
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/binascii.so:
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.1)

On Leopard, /usr/lib/libz.dylib is a 4 arch dylib, but as a rule, MacPorts ​uses its own libraries.
Therefore, /usr/lib/libz.dylib should not be used.

I am not sure how DYLD_LIBRARY_PATH relates to this question.
Although some ports make use of it, I do not think it plays a general role in MacPorts development.
In any event, we can not expect the user of these libraries to set DYLD_LIBRARY_PATH.

I agree that building a universal zlib probably is not too difficult.
Of course, zlib already supports ppc and i386 universal.
MacPorts 1.6 does not support 64-bit universal builds.
As mentioned in a previous comment, MacPorts 1.7 will support them.
I suspect that once MacPorts 1.7 is released, then zlib (and python26) could support 64-bit in short order.

[blb@…]

Note that setting DYLD_LIBRARY_PATH is almost always a bad thing (except when testing something). Since Mac OS X encodes library paths in with something linked, such things shouldn't be needed.

[Veence (Vincent)]

Replying to blb@…:

Note that setting DYLD_LIBRARY_PATH is almost always a bad thing (except when testing something). Since Mac OS X encodes library paths in with something linked, such things shouldn't be needed.

I agree. If I believe what is written in the man page of ld, the -Lpathes are searched *before* the system one, so that if a package encounters the library it needs in, e.g. ${prefix}/lib, it should link against the local library and not the default system one. I'll give it a try.

[Veence (Vincent)]

Correct. Build libz +universal first, and get:

otool -L /usr/pkg/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/binascii.so 
/usr/pkg/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/binascii.so:
	/usr/pkg/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)

So, we'll have to include an explicit dependency to port:zlib in the universal variant. Cheers. V.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I will close this ticket for now.
When MacPorts 1.7 is released, we can revisit the issue.

Thanks for the input.

[Veence (Vincent)]

Okay, when is it planned? Meanwhile, I'm going to figure out what is required to build a universal mod_python plugin. Cheers

[(none)]

Milestone Port Bugs deleted