freetype +universal fails to install

[Bengt Nilsson]

$ port variants freetype
freetype has the variants:
         universal
         bytecode: Build bytecode interpreter into the TrueType driver
         doc: Install extra documentation

When I do

# port edit freetype

I see nothing about "universal" variants in the portfile.
On the other hand, all(?) ports seem to have a "universal" variant.
Where is the scheme for creating universal variants described?

7 aug 2007 kl. 10.47 skrev Ryan Schmidt:

> On Aug 6, 2007, at 08:31, Bengt Nilsson wrote:
>
>> 6 aug 2007 kl. 14.55 skrev Bengt Nilsson:
>>
>>> Is it at all possible to build universal-binary products using  
>>> MacPorts on a ppc machine?
>>> Maybe this is the source of my problems...
>>
>> I was able to build zlib +universal successfully, so that can't be  
>> it.
>
> Right, it should work, in general, though apparently it's broken  
> for freetype in particular.
>
>> I tried this since freetype depends on zlib, and after this I got  
>> some othrer error messages that may clarify:
>
> Yes, you definitely need to build all dependencies as universal first.
>
>> mc2-p039:/Users/bnilsson root# port install freetype +universal
>> --->  Fetching freetype
>> --->  Verifying checksum(s) for freetype
>> --->  Extracting freetype
>> --->  Applying patches to freetype
>> --->  Configuring freetype
>> --->  Building freetype with target all
>> Error: Target org.macports.build returned: shell command " cd "/ 
>> opt/local/var/macports/build/ 
>> _opt_local_var_macports_sources_rsync.macports.org_release_ports_prin 
>> t_freetype/work/freetype-2.3.5" && make all " returned error 2
>> Command output: _mmap
>> _munmap
>> _open
>> _read
>> _realloc
>> _longjmp
>> _memcpy
>> _memmove
>> _memset
>> _strcat
>> _strcmp
>> _strncpy
>> _strrchr
>> _strstr
>> _qsort
>> _strncmp
>> _atol
>> _sprintf
>> _memchr
>> _setjmp
>> _memcpy referenced from libz expected to be defined in /usr/lib/ 
>> libSystem.B.dylib
>> _free referenced from libz expected to be defined in /usr/lib/ 
>> libSystem.B.dylib
>> _malloc referenced from libz expected to be defined in /usr/lib/ 
>> libSystem.B.dylib
>> _memset referenced from libz expected to be defined in /usr/lib/ 
>> libSystem.B.dylib
>> ld: warning prebinding not disabled because (__TEXT segment  
>> (address = 0x0 size = 0x6c000) of /var/tmp//cc4g3v1H.out overlaps  
>> with __TEXT segment (address = 0x0 size = 0x11000) of /opt/local/ 
>> lib/libz.1.dylib
>> ld: warning prebinding not disabled because (__TEXT segment  
>> (address = 0x0 size = 0x6c000) of /var/tmp//cc4g3v1H.out overlaps  
>> with __DATA segment (address = 0x11000 size = 0x1000) of /opt/ 
>> local/lib/libz.1.dylib
>> ld: warning prebinding not disabled because (__TEXT segment  
>> (address = 0x0 size = 0x6c000) of /var/tmp//cc4g3v1H.out overlaps  
>> with __LINKEDIT segment (address = 0x12000 size = 0x2000) of /opt/ 
>> local/lib/libz.1.dylib
>> /usr/bin/libtool: internal link edit command failed
>> lipo: can't figure out the architecture type of: /var/tmp// 
>> ccFoopYY.out
>> make: *** [/opt/local/var/macports/build/ 
>> _opt_local_var_macports_sources_rsync.macports.org_release_ports_prin 
>> t_freetype/work/freetype-2.3.5/objs/libfreetype.la] Error 1
>>
>> Error: Status 1 encountered during processing.
>>
>> It seems it tries to link to /usr/lib/libSystem.B.dylib, while I  
>> suspect it should link to /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/ 
>> libSystem.B.dylib.
>>
>> Am I right? If so, how should the portfile me changed to achieve  
>> this?
>
> That sounds plausible. Unfortunately I don't know what needs to be  
> done to achieve this. If you find out, let me know and I'll be  
> happy to update the portfile.
>
> I see one old thread in Google about an old version of freetype  
> where the advice for building freetype universal was to do it the  
> "hard" way, compiling twice with different -arch switches and  
> combining with lipo. We have a couple ports that do this, but it's  
> not exactly build into MacPorts yet, so I would need to research  
> how to do this, and then someone on PowerPC would need to test  
> whether that fixed the problem. I myself no longer have a PowerPC  
> Mac to test on. :-/ Though I'm trying to see if I can emulate it  
> somehow.
>
>
>