Innocent as it may look, I think that this patch (from Daniel M. Quinlan whose
address we don't have) creates a dangerous problem:
$ ./perl -Ilib -V:archname -V:longsize -V:ivsize -V:config_args
archname='darwin-2level';
longsize='4';
ivsize='4';
config_args='-Dusedevel -des';
$ ./perl -Ilib -V:archname -V:longsize -V:ivsize -V:config_args
archname='darwin-64int-2level';
longsize='4';
ivsize='8';
config_args='-Dusedevel -Duse64bitint -des';
$ ./perl -Ilib -V:archname -V:longsize -V:ivsize -V:config_args
archname='darwin-2level';
longsize='8';
ivsize='8';
config_args='-Dusedevel -Duse64bitall -des';
It looks like the act of changing to LP64 isn't being recorded in the archname,
which we must fix, else shared libraries which are not compatible will be
mapped onto the same pathnames.
Or does this comment in darwin.sh mean that all is safe?
# Since we can build fat, the archname doesn't need the processor type
archname='darwin';
I would assume no, as even if the linker can spot that (say)
/opt/local/lib/perl5/5.10.1/darwin-2level/auto/POSIX/POSIX.bundle
doesn't contain an architecture it can load, by default the build isn't fat,
so building a second perl to -Dprefix=/opt/local will overwrite the
architecture dependant files of the first.
So does that mean that that hints file is wrong even for 32bit stuff? In that
the archname should only be 'darwin' if we *are* building fat?
Nicholas Clark