set deployment target from macports.conf

Harry van der Wolf hvdwolf at gmail.com
Sat Aug 30 13:29:44 PDT 2008


Hi,

Some feedback on the mails from last week. Below is all done on Leopard
10.5.4 with macports trunk of dd. 30 aug 2008 (upgraded to Leopard on 29th).

some "key issues" to start with:
- sqlite3 doesn't compile universal and links (incorrectly) to a number of
libs (see below).
- fftw-3 has setting "universal_variant no", but compiles correctly
universally whith setting removed (see below).
- x264 doesn't build universally and doesn't build a .dylib. See attached
Portfile.x264 which does build universally. It compiles i386 with assembly
and ppc without (this was one of the main issues btw). As I don't know the
ins&outs of macports Portfiles I didn't manage to build a dylib (yet). Need
to take a further look at that. I will also attach Portfile.x264 to
http://trac.macports.org/ticket/15996 (Installation of x264 +universal fails
to build).
- xvid ignores deployment target and needs to be built manually.



I upgraded to Leopard. I wanted to build during the weekend but my wife had
totally other plans (happens in the best families).
I built macports from trunk with
./configure \
   --with-universal-target=10.4 \
   --with-universal-sysroot=/Developer/SDKs/MacOSX10.4u.sdk \
   --with-universal-archs="ppc i386" \
;
All compiles and installs fine.
I first did a run without universal packages. Apart from libxvid all libs I
needed built fine against target 10.4. xvid "didn't listen"  to the setting
and compiled for 10.5. So I had to deactivate that one.
I created an intel bundle for avidemux and brought it to a Tiger system. It
worked fine.
So far so good. (I will have a look at xvid next week).

Then I wanted to build universally. I removed /opt completely and built
macports again from trunk.
I added "+universal +no_x11" to variants.conf (as I want an avidemux QT4 and
Gtk version without X11).
Than I tried to build my packages universal which was not completely
succesful.
I needed subversion. This does not build universal as sqlite3 and
cyrus-sasl2 don't build universal (yet). As such I don't care as they don't
need to be universal. So I uninstalled all underlying depndent packages and
did a "sudo port install subversion -universal" and that went fine.
However, when I tried to build tiff universally it crashed on sqlite3 (??)
during linking as it could not find a ppc version of it.
(ld: in /opt/local/lib/libsqlite3.0.dylib, file is not of required
architecture for architecture ppc
collect2: ld returned 1 exit status
)
I did a sudo port deactivate sqlite3; sudo port install tiff; sudo port
activate sqlite3;
Now "my" tiff was nicely build as universal version. I did not file a bug
report yet for this, but I think I have to. It's really weird that tiff
links to sqlite3.

Then I went on with the rest of the libs. One of them was libsndfile (as
dependency for libsamplerate). Again the linking crashed on sqlite3
<snippet>
Undefined symbols for architecture ppc:
  "_sqlite3_open", referenced from:
      _db_open in database.o
</snippet>
I did a "sudo port deactivate sqlite3"  and started again.
Now libsndfile builds correctly. Again: why is ld trying to link against
sqlite3?
Than is continued with libsamplerate and it crashed on;
ld warning: in /opt/local/lib/libfftw3.dylib, file is not of required
architecture
Undefined symbols for architecture ppc:
  "_fftw_plan_r2r_1d", referenced from:
      _calculate_snr in multi_channel_test-calc_snr.o
  "_fftw_destroy_plan", referenced from:
      _calculate_snr in multi_channel_test-calc_snr.o
  "_fftw_execute", referenced from:
      _calculate_snr in multi_channel_test-calc_snr.o
ld: symbol(s) not found for architecture ppc
collect2: ld returned 1 exit status
lipo: can't open input file: /var/tmp//ccw3Wmmx.out (No such file or
directory)
make[1]: *** [multi_channel_test] Error 1
make: *** [all-recursive] Error 1

However, fftw3 reported earlier to have been built succesfully:
--->  Fetching fftw-3
--->  Attempting to fetch fftw-3.1.2.tar.gz from
ftp://ftp.fftw.org/pub/fftw/
--->  Verifying checksum(s) for fftw-3
--->  Extracting fftw-3
--->  Configuring fftw-3
--->  Building fftw-3
--->  Staging fftw-3 into destroot
--->  Installing fftw-3 @3.1.2_6
--->  Activating fftw-3 @3.1.2_6
--->  Cleaning fftw-3
A lipo -info /opt/local/lib/libfftw3.dylib showed that it was "only" i386
compiled.
So I just gave it a shot and removed the "universal_variant no" and build it
again. It builds fine (lipo -info shows "/opt/local/lib/libfftw3.dylib are:
ppc i386 "), I did not yet have the chance to check whether it really
functions correctly on ppc too.

From this point also libsamplerate builds correctly universally.

x264 does not build correctly universally and the Portfile needed to be
patched (see attached).
xvid builds correctly as such but ignores deployment target (need to sort
that out).

Harry


2008/8/22 Harry van der Wolf <hvdwolf at gmail.com>

> Thanks for the hints and the fast response. The options
> universal_target        10.4
> universal_sysroot       /Developer/SDKs/MacOSX10.4u.sdk
> universal_archs         ppc i386
>
> are exactly what I was looking for.
>
>
> It seems that I have an exciting (or frustrating) weekend coming up. I will
> install/build from trunk and compile the first ports with -d to see whether
> it does what I want them to do.
>
> I will let you know about my experiences.
>
> Harry
>
> 2008/8/22 Ryan Schmidt <ryandesign at macports.org>
>
>
>> On Aug 22, 2008, at 04:39, Anders F Björklund wrote:
>>
>>  Ryan Schmidt wrote:
>>>
>>>  Theoretically +universal should be able to handle this,
>>>>> but cross-compiling isn't really supported in MacPorts.
>>>>>
>>>>
>>>> Yeah. So why did we expose the options in macports.conf again? :)
>>>>
>>>
>>> Note that macports.conf in trunk has some more features...
>>> (which still isn't "supported", but rather "experimental")
>>>
>>> universal_target        10.4
>>> universal_sysroot       /Developer/SDKs/MacOSX10.4u.sdk
>>>
>>
>> Right, those are the options I was referring to.
>>
>>
>>  universal_archs         ppc i386
>>>
>>> That has a somewhat better chance of making the right
>>> thing than hacking macosx_deployment_target or flags.
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-users/attachments/20080830/367c9e11/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Portfile.x264
Type: application/octet-stream
Size: 4058 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-users/attachments/20080830/367c9e11/attachment.obj 


More information about the macports-users mailing list