On Tuesday, November 4, 2003, at 04:39 PM, Scott Lamb wrote:
On Nov 4, 2003, at 12:27 PM, Scott Lamb wrote:
3) dynamically loading libraries. libgaim builds its prpls (protocol
plugins) to load dynamically via gmodule (which does a dlopen() and
similar, I assume). I can't get them to load; it always says it can't
find the protocol plugin.
My programming language Fexl also relies on dlopen-style dynamic
libraries, and I've recently been porting it to Mac OSX and going
through the trial by fire.
Forgive me if my comments here seem to be "random observations," I
suppose that's what they are.
Currently it's building them as libBLAH.so. I'm not quite sure what
that is. I know that under Linux, .so = shared object; I'd use it
where I'd use a .dylib under OS X. So I suspect that these should
actually be named .dylib. But file tells me they are different than
dylibs somehow: ...
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.
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".
I am finding that if I stray from these two rules in any way, things do
not work. I can't use gcc -bundle to build the first type of library,
and I can't use libtool to build the second kind.
So far I have been naming the first kind of library ".so" and the
second kind of library ".dylib". However, I do find that the suffix
really doesn't matter.
All I know is that I MUST use "gcc -bundle" to build the run-time
loaded fexl_test module. If I don't, then the dlopen call in my main
program does not find the function.
I find the .so versus .dylib distinction confusing, particularly now
that I see the contradiction between your usage and mine.
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.
And Under Linux, a .so is
$ file libc-2.3.2.so
libc-2.3.2.so: ELF 32-bit LSB shared object, Intel 80386, version 1
(SYSV), stripped
I'm also going to ask about this on the gaim list (since there seem
to be a lot of project-specific configure options about this) but the
.so/.dylib question is likely to come up, and I don't think there are
any OS X people on that list.
With some more searching, I think I've got the answer. libXXX.so is
for dynamic loading. libXXX.dylib is for dynamic linking. libXXX.a is
for static linking. You can toggle between generating .sos and .dylibs
by adding or not adding the -module line to GNU libtool. So libgaim is
actually doing the right thing here. And I saw that gmodule has had OS
X support specifically added, so it should be able to load them. It's
still not working, but I think I'm in good shape for getting it
figured out on my own or with the gaim people.
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".
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.
I'd still appreciate help with #1 and #2...I'm completely stumped
there.
I was up until 2am this morning dinking around with this stuff, trying
all sorts of command combinations. I hope you find my observations
helpful.
