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.
Well, its bit longer than the $(SO) that we have everywhere now, but it
works fine for me.
What about $(SO) and $(LO)?
jens
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. Fdynclasses/ was intended for experiments with that
stuff. Now its working and we are
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
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
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 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 add,
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 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
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
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 like
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 with
, 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
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 things are
14 matches
Mail list logo
