I've got #3 conquered now, so let me see how what I've read/observed
matches up with your observations:
On Nov 4, 2003, at 5:23 PM, Patrick Chkoreff wrote:
As far as I can tell, the "dylib" versus "so" suffix is only a
difference in convention and of course the only thing that matters is
how you build the file.
That's generally true in Unix - you could call your C source files .o
and your object files .c and it'd still work, for example. But the
conventions should probably be followed when you know what they are
(see below).
Through experimentation I've got it down to two simple rules I think I
can obey and consistently get things to work:
1. If I want to create an ordinary shared library that I link with my
program at build time, I must use the command "libtool -dynamic".
2. If I want to create a dynamic library that my program loads at run
time, I must use the command "gcc -bundle".
These libraries use GNU libtool (which under OS X tends to be called
glibtool; it's a really different tool than the vanilla libtool is,
despite glibtool being called libtool on other platforms. Ugh.) The
difference between #1 and #2 is just a "-module" for #2, and they set
the names automatically.
That is backwards from all my system-installed libraries in /usr/lib
(I'd imagine yours, too), so you should probably think about switching
them for consistency.
The entire subject of dynamic libraries in general is so shrouded in
obfuscation and tedious, example-poor documentation that I can only
rely on empirical scientific experimentation to establish procedural
rules I can follow to get reasonably reliable results. I have no
genuine deep understanding of what's actually going on there.
I know exactly what you mean. I think it's not really that hard - if
someone took the time to write some really good documentation, we
wouldn't have to wonder. But no one's done that so far.
Ignoring the difference in .so and .dylib suffixes for just a moment,
let me just make this observation and see if it sticks.
OBSERVATION: If I want to load a library dynamically at run-time,
then the type of that library (using the "file" command) must be:
"Mach-O bundle ppc".
Apparently there is one exception - the dlcompat library can also
dynamically load the other kind, with the restriction that it can't
_unload_ them. I don't know of any other library can do this. Although
since dlcompat is implemented on top of dyld, dyld must be able to,
though it might not be easy. See
<http://www.opendarwin.org/cgi-bin/cvsweb.cgi/proj/dlcompat/README?
rev=1.8&content-type=text/x-cvsweb-markup>
But generally, I think you're correct - the bundles are for dynamic
loading, the shared libraries are for dynamic linking, and never the
twain shall meet.
Now, if that observation is true, and it seems to be true at least on
my computer, then it seems directly relevant to what you say above:
I can't get them to load; it always says it can't find the protocol
plugin.
I am suggesting that is because your .dylib file is of type "Mach-O
dynamically linked shared library ppc," and in my experience that type
of file will NOT load at runtime.
It turns out in my case it was something much stupider. :/ I'd put my
plugins in a different place than the other Adium people, and I didn't
notice that the Adium code was always responsible for telling it where
to look for the libraries. I'd thought since I was putting it in the
default location, it'd just figure it out. The .so files were fine.
Once I finally read enough to know there was nothing wrong with .sos, I
looked back at the more basic stuff and found this. Oh well...I guess I
learned something in the process, anyway.
Good luck with your language.
Scott
_______________________________________________
unix-porting mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/unix-porting
Do not post admin requests to the list. They will be ignored.
