John Siracusa <[EMAIL PROTECTED]> writes: > I'm cc-ing this to the Mac OS X Perl list in the hopes that someone can > provide a test environment for you. (I would, but my OS X box is behind a > firewall at work.) > > So how about it, [EMAIL PROTECTED] folks, can any of you help get libapreq up > and running on OS X an long last? (See message quoted below) >
Maybe this will help: http://fink.sourceforge.net/doc/porting/porting.html The Unix build of libapreq goes in 3 steps: 1) build a static c library: libapreq.a 2) build object files Request.o, Cookie.o 3) link each object file against libapreq.a to make shared libraries Request.so Cookie.so So each file gets it's own copy of libapreq, symbols and all. For ELF-based systems, that's not a problem since the linking executable knows not only the library's filename, but also the location of the desired symbol within the file (actually there's something called a jump table inside the .so that provides some necessary indirection, but that's a technicality that's not particularly relevant to the issue.) AIUI, the problem with OS/X is that their linker doesn't provide the executable with a similar addressing scheme for unresolved symbols; it just tells the executable which libraries are needed to resolve them without also telling it "where to look" for a given symbol. So because Request.bundle and Cookie.bundle both (accidentally?) provide resolution for libapreq's symbols, the executable gets confused and bails out. If I'm right here, then removing the libapreq symbols from Cookie.bundle and Request.bundle should do the trick. There are lots of ways to reorganize things in order to achieve this, and I'm somewhat surprised that none of the OS/X folks have made any progress in this regard. So maybe I'm wrong, but I don't think any of us will learn the answer until some OS/X person actually _attempts_ to fix it. -- Joe Schaefer
