On Oct 8, 2004, at 7:54 AM, Andy Dougherty wrote:
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 li
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> 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
On Oct-08, Andy Dougherty wrote:
>
> 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 ad
Sam Ruby <[EMAIL PROTECTED]> 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"?
PARROT_LOAD_EXT and PARROT_SHARE_EXT are defined in
include/parrot/config.h.
>> src/dynext.c:147: error:
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)
Leopold Toetsch wrote:
Steve Fink <[EMAIL PROTECTED]> 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 funct
Steve Fink <[EMAIL PROTECTED]> wrote:
> 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 was intended for experiments with that
stuff. Now its working and we are able to
> Well, its bit longer than the $(SO) that we have everywhere now, but it
> works fine for me.
What about $(SO) and $(LO)?
jens
Ok, it's in. I did not add the 'cd dynclasses; make' to the default
target; I though I'd see what regular builds I broke first. Testers
wanted, especially on platforms other than darwin and linux.
On Oct-07, Dan Sugalski wrote:
> At 9:55 PM +0200 10/7/04, Leopold Toetsch wrote:
> >Steve Fink <[EMAIL PROTECTED]> 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
gt; 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 (an
At 9:55 PM +0200 10/7/04, Leopold Toetsch wrote:
Steve Fink <[EMAIL PROTECTED]> 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 wit
Steve Fink <[EMAIL PROTECTED]> 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 li
ing, 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
14 matches
Mail list logo
