In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Dan Kogai) wrote:
As you see ${ldflags} is injected into $lddlflags but in case of -prebind we need to avoid that. $ldflags is for perl linking while $lddlflags is for XS. Since -prebind and -bundle are mutually exclusive, we do not want -prebind in $lddlflags (though CC on darwin is smart enough to ignore -prebind when -bundle, it still issues warnings and I don't want to see that warning for each XS gets built).
Another question is whether to use something other than bundle for XS, to
allow prebinding. I have a patch to dl_dyld.xs that seems to work; it
allows both bundle and dyld (thanks to some pointers from wsanchez).
That's a great work but with all due respect I do not think making XS prebindable a good idea. Correct me if I am wrong but my understanding on prebinding is that it is a technique that makes dynamic libraries behave like static ones by predetermining ALL ADDRESSES IN NEED A PRIORI.
With -Uuseshrplib, the only dynamic library you need is libSystem (which is what libc and libm really are). So it is safe to assume that no addresses would collide.
% otool -L ./perl
./perl:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 63.0.0)
But to make XS prebindable you have to make sure that addresses never collide FOR ALL MODULES. When that fails XS may still work (so far as I see dyld is smart enough to make sure to to collide symbols and addresses and diverts that when it needs but when that happens a warning is issued).
Since no one knows how many XSes a particular user needs, I think we should leave -bundle for XS.
Theoretically, however, we can still resolve this by keeping a symbol table handy somewhere and use that during XS builds but that I consider a too much work.
Dan the Prebound Man
