Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:13762
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <418D8C03.8070404@mainstreetsoftworks.com>
Date: Sat, 06 Nov 2004 21:44:19 -0500
User-Agent: Mozilla Thunderbird 0.9 (X11/20041105)
MIME-Version: 1.0
To: internals@lists.php.net
Cc: Andrei Zmievski <andrei@gravitonic.com>,
	Shane Caraveo <shane@caraveo.com>
References: <39F7BCBE-29F5-11D9-88E3-000D93B4252E@gravitonic.com> <418482F7.4050708@caraveo.com> <0076D0DA-3064-11D9-A5B3-000D93B4252E@gravitonic.com>
In-Reply-To: <0076D0DA-3064-11D9-A5B3-000D93B4252E@gravitonic.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP_SHLIB_SUFFIX and OS X
From: brad@mainstreetsoftworks.com (Brad House)

I guess I'm stepping in, in the middle of the conversation,
but dylibs and so's are totally different on MacOSX.
One of those OS X MACH-O oddities.
.dylib's are libraries which you link against, and are loaded at
runtime. (Shared Library)
.so's are something you can dlopen() (as of 10.3, don't remember
the 10.2 similar functions)... (Loadable Module)

Please note that these are _not_ interchangeable.  You cannot
link against a .so, and you cannot dlopen() a .dylib on MacOSX.

If you decide to name all libraries .dylib, even those that are
meant to be dynamically loaded via dlopen, you will add a lot
of confusion into the mix... which is why libtool is most likely
not cooperating.

A good reference on this is here:
http://fink.sourceforge.net/doc/porting/shared.php?phpLang=en#lib-and-mod

-Brad

Andrei Zmievski wrote:
> Sticking with .dylib across the board is fine with me, but try telling 
> that to libtool. For some reason it wants to stick to .so extension, 
> instead of .dylib and I just do not have the time or effort to debug the 
> beast that is libtool. Any hints on how to make it use .dylib?
> 
> -Andrei
> 
> On Oct 30, 2004, at 11:15 PM, Shane Caraveo wrote:
> 
>> Not a real suggestion, but a comment on this...
>>
>> There is no reason to use dylib for libraries that will only be loaded 
>> by php.  the php library itself should be .dylib, by php extensions 
>> *can* be .so.  Python works this way.  However, I'm not convinced it's 
>> the best thing, as it does lead to further confusion.  Sticking with 
>> dylib across the board is much clearer.
>>
>> The only questionable part is the sapi modules, where it would depend 
>> more on what is loading the sapi.
> 
>