On Apr 8, 2012, at 01:00, Jeremy Huddleston wrote:
> Yes, adding a ton of -l in the right places will certainly fix the issue, but
> my way was quicker and uses a toolchain that I trust much more. ;) I don't
> see why you would've only seen this with +universal, but if you recall a
> case, I'
On Apr 8, 2012, at 01:00, Jeremy Huddleston wrote:
>> Oh yes, this looks familiar. This is the problem we fixed in many ports by
>> manually adding lots of -l flags, yes? I seem to also remember it only
>> occurring on universal builds, though that doesn't appear to be the case you
>> quoted a
On Apr 7, 2012, at 10:37 PM, Ryan Schmidt wrote:
>
> On Apr 8, 2012, at 00:31, Jeremy Huddleston wrote:
>
>> The most common symptom is a list of unsatisfied symbols at link time. Here
>> is an example from the latest version of libquicktime without the change:
>>
>> /bin/sh ../libtool --ta
On Apr 8, 2012, at 00:31, Jeremy Huddleston wrote:
> The most common symptom is a list of unsatisfied symbols at link time. Here
> is an example from the latest version of libquicktime without the change:
>
> /bin/sh ../libtool --tag=CC --mode=link /usr/bin/gcc-4.0
> -DLOCALE_DIR=\"/opt/loc
The main reason for this is not so much a bug in the compiler, but rather the
linker. On Tiger, the default linker comes from cctools and is quite archaic.
It is very finicky about ordering on the command line, and it has just been
easier to "fix" this by using our newer linker than /usr/bin/l
I see lots of revisions like r91601 being committed where the apple-gcc42 port
is being used as the compiler on Tiger to work around problems with the old
compilers in Tiger's Xcode.
Could this be added to the PortfileRecipes wiki page? Specifically I'm trying
to figure out how to know if a par
