Ah... it's a difference in -ljbig : /usr/bin/file /opt/local/lib/libjbig.dylib /opt/local/lib/libjbig.dylib: Mach-O 64-bit dynamically linked shared library x86_64
Looks like jbigkit lies about being universal... --- libtiff.la.i386 2009-12-10 14:25:50.000000000 -0800 +++ libtiff.la.x86_64 2009-12-10 14:26:02.000000000 -0800 @@ -17,7 +17,7 @@ old_library='libtiff.a' inherited_linker_flags=' ' # Libraries that this one depends upon. -dependency_libs=' -L/opt/local/lib /opt/local/lib/libjpeg.la -lz -lc' +dependency_libs=' -L/opt/local/lib -ljbig /opt/local/lib/libjpeg.la -lz -lc' # Names of additional weak libraries provided by this library weak_library_names=''
libtiff.la.x86_64
Description: Binary data
libtiff.la.i386
Description: Binary data
On Dec 10, 2009, at 12:19, Ryan Schmidt wrote: > Jeremy, allow me to bring this to the macports-dev list... > > On Dec 10, 2009, at 13:23, Jeremy Huddleston wrote: > >> On Dec 1, 2009, at 19:34, [email protected] wrote: >> >>> Revision: 61108 >>> http://trac.macports.org/changeset/61108 >>> Author: [email protected] >>> Date: 2009-12-01 19:34:12 -0800 (Tue, 01 Dec 2009) >>> Log Message: >>> ----------- >>> muniversal-1.0.tcl: compare contents of compressed files, not the >>> compressed files themselves; see #22650 >> >> I think you may have broken muniversal with this change. See attached log >> for installing tiff. >> >> <main.log> > >> :debug:destroot Backtrace: /opt/local/lib/libtiff.la differs in >> /opt/local/var/macports/build/_Users_jeremy_src_macports-trunk_dports_graphics_tiff/work/destroot-i386 >> and >> /opt/local/var/macports/build/_Users_jeremy_src_macports-trunk_dports_graphics_tiff/work/destroot-x86_64 >> and cannot be merged > > That wasn't because of r61108, but because of r61090. And that revision > wouldn't have broken tiff or any other port; that revision merely causes > MacPorts to notify you that tiff +universal is already broken. Before, you > would've gotten a broken .la file without knowing it. muniversal tries to > merge files using C/C++ preprocessor directives, which are not appropriate > for .la files or .pc files or -config scripts. muniversal previous assumed > those types of files would never differ. Sometimes they do. So r61090 now > actively prevents those files from being merged. See #21953 for the long list > of related confusing issues that had previously been caused by not having > this in place. > > This change will probably reveal many ports that have been broken all along. > For example a ticket was filed for pango +quartz +universal. I don't know how > to fix it but now we at least prevent users from installing software that > they think is working properly when it really isn't. > > In the case of tiff, though, it installs fine for me. So I would be > interested for you to show me how libtiff.la differs between your two > destroots. Could you send me those two libtiff.la files, or run a diff -ru > between your two destroots and see how they (and perhaps other files) differ? > One common reason why such files might differ is if one of the dependencies > (jpeg, zlib) wasn't built universal. If that's the reason here, we could add > archcheck to tiff to prevent it in the future. > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
