dynamically loadable modules
Steve Fink
and I seem to have it working now. (Oh, and it fixes the Linux build
too.) It's a fairly large change, and I would like to use standard
naming conventions throughout, but I haven't really found any
convincing, definitive source of terminology.
The issue is that on some platforms, dynamically loadable modules and
shared libraries are different things. Although you may know them under
different names (and one of those names is often used for the other.)
A dynamically loadable module is something you explicitly load after
startup time, via dlopen() or some similar interface. A shared library
is implicitly loaded at startup time; you can see a list of these under
unix with ldd.
Under Linux, they both end in a .so extension and are built the same
way. Under Darwin, shared libraries end in .dylib and d-l-modules end in
whatever you want them to. The former is compiled with something like
-dynamiclib and the latter with -bundle (or something; I don't remember
exactly).
So what I need is names for these. At the moment, I'm mostly using $(SO)
for shared lib extensions, $(DYNMOD) for d-l-modules. The buildflags I
gneerally call $(LD_SHARED) or something with shared for shared libs,
and something like $(LD_DYNMOD_FLAGS) for d-l-modules.
Clearly, I'm not very experienced with dealing with these things across
platforms, so I was hoping somebody (Andy?) might have a better sense
for what these things are called.
Leopold Toetsch
[ snip explanation ]
> So what I need is names for these. At the moment, I'm mostly using $(SO)
> for shared lib extensions, $(DYNMOD) for d-l-modules. The buildflags I
> gneerally call $(LD_SHARED) or something with shared for shared libs,
> and something like $(LD_DYNMOD_FLAGS) for d-l-modules.
That's fine with me. Would be nice to have for the release.
> Clearly, I'm not very experienced with dealing with these things across
> platforms, so I was hoping somebody (Andy?) might have a better sense
> for what these things are called.
AOL ;)
leo
Dan Sugalski
>Steve Fink <st...@fink.com> wrote:
>
>[ snip explanation ]
>
>> So what I need is names for these. At the moment, I'm mostly using $(SO)
>> for shared lib extensions, $(DYNMOD) for d-l-modules. The buildflags I
>> gneerally call $(LD_SHARED) or something with shared for shared libs,
>> and something like $(LD_DYNMOD_FLAGS) for d-l-modules.
>
>That's fine with me. Would be nice to have for the release.
Yup. I think I'd like to hold the release of 0.1.1 to get this done,
unless it'll take ages to do.
> > Clearly, I'm not very experienced with dealing with these things across
>> platforms, so I was hoping somebody (Andy?) might have a better sense
>> for what these things are called.
>
>AOL ;)
Heh. If Andy doesn't have a good name, let's call them shareable and
loadable libraries, LD_SHARE_FLAGS and LD_LOAD_FLAGS for the flags,
and SHARE_EXT and LOAD_EXT for the extensions. (All subject to
wholesale pitching if there's a better name :)
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Jonathan Polley
That's actually pretty interesting to me to hear. I sort of hacked a
project that relied on dynamically loaded plugin modules to build on OSX,
and I ended up using the '-dynamiclib' flag to gcc to produce files that
file refers to as "Mach-O dynamically linked shared library ppc" which I
then open with dlopen (which is really some sort of magic compatibility
wrapper). I always had a certain feeling that I wasn't doing it right,
but it worked and I had more important things to fix.
--
Jonathan
Steve Fink
> At 9:55 PM +0200 10/7/04, Leopold Toetsch wrote:
> >Steve Fink <st...@fink.com> wrote:
> >
> > > Clearly, I'm not very experienced with dealing with these things across
> >> platforms, so I was hoping somebody (Andy?) might have a better sense
> >> for what these things are called.
> >
> >AOL ;)
>
> Heh. If Andy doesn't have a good name, let's call them shareable and
> loadable libraries, LD_SHARE_FLAGS and LD_LOAD_FLAGS for the flags,
> and SHARE_EXT and LOAD_EXT for the extensions. (All subject to
> wholesale pitching if there's a better name :)
Well, its bit longer than the $(SO) that we have everywhere now, but it
works fine for me. If I can disentangle my patch from some other stuff
that somehow crept in (I've no idea how; I'm using a virgin tree for
this), I'll commit it under those names for now.
Steve Fink
target; I though I'd see what regular builds I broke first. Testers
wanted, especially on platforms other than darwin and linux.
Jens Rieks
> works fine for me.
jens
Leopold Toetsch
> Ok, it's in.
Great, thanks, works fine.
> ...I did not add the 'cd dynclasses; make' to the default
> target; I though I'd see what regular builds I broke first.
That's ok. F<dynclasses/> was intended for experiments with that
stuff. Now its working and we are able to bundle classes. We can
start with the real fun in languages/*/classes/.
leo
Sam Ruby
> Steve Fink <st...@fink.com> wrote:
>
>>Ok, it's in.
>
> Great, thanks, works fine.
Doesn't compile for me on Debian. Did a header file change not get
checked in?
> src/dynext.c: In function `get_path':
> src/dynext.c:147: error: `PARROT_LOAD_EXT' undeclared (first use in this function)
> src/dynext.c:147: error: (Each undeclared identifier is reported only once
> src/dynext.c:147: error: for each function it appears in.)
> src/dynext.c:176: error: `PARROT_SHARE_EXT' undeclared (first use in this function)
> make: *** [src/dynext.o] Error 1
- Sam Ruby
Andy Dougherty
> So what I need is names for these. At the moment, I'm mostly using $(SO)
> for shared lib extensions, $(DYNMOD) for d-l-modules. The buildflags I
> gneerally call $(LD_SHARED) or something with shared for shared libs,
> and something like $(LD_DYNMOD_FLAGS) for d-l-modules.
>
> Clearly, I'm not very experienced with dealing with these things across
> platforms, so I was hoping somebody (Andy?) might have a better sense
> for what these things are called.
Sorry -- offhand I don't have any sense of any "standard" names, and I
won't have time till late next week to look at it at all. The most
important thing is to *DOCUMENT CAREFULLY* exactly what the names are and
what they mean.
Whatever names you add, please list them in config/init/data.pl along with
a nice good long verbose description of exactly what they are. See
the existing entries for cc, link, and ld for some good examples. See
ld_shared and ld_shared_flags for some bad examples.
--
Andy Dougherty doug...@lafayette.edu
Leopold Toetsch
> Doesn't compile for me on Debian. Did a header file change not get
> checked in?
Did you reconfigure: "perl Configure.pl", possibly after "make clean"?
PARROT_LOAD_EXT and PARROT_SHARE_EXT are defined in
include/parrot/config.h.
>> src/dynext.c:147: error: `PARROT_LOAD_EXT' undeclared (first use in this function)
>> src/dynext.c:176: error: `PARROT_SHARE_EXT' undeclared (first use in this function)
> - Sam Ruby
leo
Steve Fink
>
> Sorry -- offhand I don't have any sense of any "standard" names, and I
> won't have time till late next week to look at it at all. The most
> important thing is to *DOCUMENT CAREFULLY* exactly what the names are and
> what they mean.
>
> Whatever names you add, please list them in config/init/data.pl along with
> a nice good long verbose description of exactly what they are. See
> the existing entries for cc, link, and ld for some good examples. See
> ld_shared and ld_shared_flags for some bad examples.
Well, my documentation isn't very verbose, but it's there. I suppose I
should expand it a little bit. As for ld_shared and ld_shared_flags -- I
really couldn't figure out what the intention was, because the
implications of the names didn't match how they were actually being
used. I guessed that ld_shared would be the command used to link shared
libraries, and ld would be the command to link executables. But they
weren't. So I deleted both and replaced them with a single
ld_share_flags. If we need a different linker for shared libs or
loadable modules on some platform, we can reintroduce it when we
encounter the problem.
Sam Ruby
> Sam Ruby <ru...@intertwingly.net> wrote:
>
>>Doesn't compile for me on Debian. Did a header file change not get
>>checked in?
>
> Did you reconfigure: "perl Configure.pl", possibly after "make clean"?
DOH! Thanks.
- Sam Ruby
Jeff Clites
> On Thu, 7 Oct 2004, Steve Fink wrote:
>
>> So what I need is names for these. At the moment, I'm mostly using
>> $(SO)
>> for shared lib extensions, $(DYNMOD) for d-l-modules. The buildflags I
>> gneerally call $(LD_SHARED) or something with shared for shared libs,
>> and something like $(LD_DYNMOD_FLAGS) for d-l-modules.
>>
>> Clearly, I'm not very experienced with dealing with these things
>> across
>> platforms, so I was hoping somebody (Andy?) might have a better sense
>> for what these things are called.
>
> Sorry -- offhand I don't have any sense of any "standard" names
I don't think it's common to have a split like the dylib v. bundle
split on Mac OS X, so there's probably not a common convention.
JEff