Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#17309 closed defect (invalid)

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

Reported by: Veence (Vincent) Owned by: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Priority: Normal Milestone:
Component: ports Version: 1.6.0
Keywords: Cc: blb@…
Port: python26

Description

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.

Change History (11)

comment:1 Changed 15 years ago by mf2k (Frank Schima)

Cc: mcalhoun@… added
Owner: changed from macports-tickets@… to blb@…
Port: python26 added

comment:2 Changed 15 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Owner: changed from blb@… to mcalhoun@…
Status: newassigned

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.

comment:3 Changed 15 years ago by jmroot (Joshua Root)

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

comment:4 Changed 15 years ago by 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?

comment:5 Changed 15 years ago by 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.

comment:6 Changed 15 years ago by blb@…

Cc: blb@… added; mcalhoun@… removed

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.

comment:7 in reply to:  6 Changed 15 years ago by 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.

comment:8 Changed 15 years ago by 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.

comment:9 Changed 15 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Resolution: invalid
Status: assignedclosed

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

Thanks for the input.

comment:10 Changed 15 years ago by 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

comment:11 Changed 15 years ago by (none)

Milestone: Port Bugs

Milestone Port Bugs deleted

Note: See TracTickets for help on using tickets.