At 8:55 PM -0700 5/23/04, Steve Fink wrote:
On May-15, Jeff Clites wrote:
When linking against ("using") a static library version of ICU, we need
a C++-aware linker (because ICU contains C++ code); with a
dynamic-library version of ICU presumably we wouldn't.
I don't know if this applies here, b
On May-15, Jeff Clites wrote:
>
> When linking against ("using") a static library version of ICU, we need
> a C++-aware linker (because ICU contains C++ code); with a
> dynamic-library version of ICU presumably we wouldn't.
I don't know if this applies here, but there is a good reason to use a
Saturday, May 15, 2004, 6:02:57 PM, Jeff Clites wrote:
>> Of course, to build ICU the flags would be necessary, but we're not
>> building it directly - we are asking it to build itself, and then we
>> just link to the resulting library, which shouldn't need anything
>> special. Am I getting thing
On May 14, 2004, at 3:30 PM, Ron Blaschke wrote:
Friday, May 14, 2004, 11:48:00 PM, Andy Dougherty wrote:
IMHO, we are currently talking C only, so that shouldn't be a
problem. I
hope anybody tells me if I'm wrong.
Still, I am curious. Why would the linker need to know about C or
C++?
I though
On Fri, 14 May 2004, Ron Blaschke wrote:
> IMHO, we are currently talking C only, so that shouldn't be a problem. I
> hope anybody tells me if I'm wrong.
> Still, I am curious. Why would the linker need to know about C or C++?
I thought ICU contained some C++ files. As to why we care, you migh
Friday, May 14, 2004, 11:48:00 PM, Andy Dougherty wrote:
>> IMHO, we are currently talking C only, so that shouldn't be a problem. I
>> hope anybody tells me if I'm wrong.
>> Still, I am curious. Why would the linker need to know about C or C++?
> I thought ICU contained some C++ files. As to
On Fri, 14 May 2004 09:11:32 +0200, Bernhard Schmalhofer wrote:
> I have little expertise in building libraries on many platforms. But
> aren't these issues all addressed by GNU's 'libtool'. Is there a
> licensing reason for not using that?
autoconf, automake and libtool address the issues we a
On Thu, 13 May 2004 17:23:18 -0700, Jeff Clites wrote:
>> xxx_STATIC_BUILDcflags and ldflags to build static parrot
> We should make it clear that we are talking about building a static lib
> (to distinguish from what the next macro is intended for)--so how
> about:
> xxx_STATIC_LIB_BUILD or
On Thu, 13 May 2004 10:00:53 -0400 (EDT), Andrew Dougherty wrote:
> You might want to review the patch I submitted about a year and a half ago
> -- it's # 18319, and it included some (but certainly not all) of your good
> ideas.
Thanks, I'll do that.
> I gather parrot's now trying to include stu
On Wed, 12 May 2004, Ron Blaschke wrote:
> I have finally sorted out the details of the flags stuff, which I will
> present below. Any comments are highly appreciated. Be warned: I am going
> to implements this if there are no objections. ;-)
You might want to review the patch I submitted about
Dan Sugalski wrote:
At 5:23 PM -0700 5/13/04, Jeff Clites wrote:
[Most commentary snipped, as it's dead-on]
- When building / using a shared parrot the compiler macro
PARROT_LIB_DYNAMIC will be defined, for static PARROT_LIB_STATIC
What will these be used for? Traditionally, there aren't compile-t
At 5:23 PM -0700 5/13/04, Jeff Clites wrote:
[Most commentary snipped, as it's dead-on]
- When building / using a shared parrot the compiler macro
PARROT_LIB_DYNAMIC will be defined, for static PARROT_LIB_STATIC
What will these be used for? Traditionally, there aren't
compile-time difference when
At 5:47 PM -0700 5/13/04, Brent 'Dax' Royal-Gordon wrote:
Jeff Clites wrote:
Alternatively, we could just parse embed.h -- all and only symbols
defined there should be exported. (I believe that's the plan.)
Nope. Any symbol in a file included from embed.h and outside of an
"#if defined(PARROT_IN
On Thu, 13 May 2004, Jeff Clites wrote:
> > - When building / using a shared parrot the compiler macro
> > PARROT_LIB_DYNAMIC will be defined, for static PARROT_LIB_STATIC
>
> What will these be used for? Traditionally, there aren't compile-time
> difference when building a static v. dynamic libra
Jeff Clites wrote:
Alternatively, we could just parse embed.h -- all and only symbols
defined there should be exported. (I believe that's the plan.)
Nope. Any symbol in a file included from embed.h and outside of an "#if
defined(PARROT_IN_CORE)" is fair game for embedders. See interpreter.h
fo
On May 12, 2004, at 1:26 PM, Ron Blaschke wrote:
I have finally sorted out the details of the flags stuff, which I will
present below. Any comments are highly appreciated. Be warned: I am
going
to implements this if there are no objections. ;-)
- Targets "shared" and "static" are provided, to b
I have finally sorted out the details of the flags stuff, which I will
present below. Any comments are highly appreciated. Be warned: I am going
to implements this if there are no objections. ;-)
- Targets "shared" and "static" are provided, to build a shared or static
parrot library.
- The fol
Saturday, May 8, 2004, 11:39:03 PM, Dan Sugalski wrote:
> Another todo list task for the interested. A perl & linker thing.
>
> Right now, through the wonders of the Unix default linking
> conventions, every function in parrot gets exported whether we want
> them to be o
At 9:04 PM +0200 5/8/04, Ron Blaschke wrote:
On Wed, 5 May 2004 13:59:14 -0400, Dan Sugalski wrote:
Another todo list task for the interested. A perl & linker thing.
Right now, through the wonders of the Unix default linking
conventions, every function in parrot gets exported whether we want
On Wed, 5 May 2004 13:59:14 -0400, Dan Sugalski wrote:
>>> Another todo list task for the interested. A perl & linker thing.
>>>
>>> Right now, through the wonders of the Unix default linking
>>> conventions, every function in parrot gets exported whether we want
>>> them to be or not, and gen
On May 5, 2004, at 12:06 PM, Dan Sugalski wrote:
At 7:57 PM +0100 5/5/04, Nicholas Clark wrote:
On Wed, May 05, 2004 at 08:59:03AM -0400, Dan Sugalski wrote:
Yeah, that's what I'm figuring. The symbols themselves should be
cross-platform, modulo the odd prefix character, or so I hope. The
linker
On Wed, 5 May 2004 13:59:14 -0400, Dan Sugalski wrote:
>>Windows requires this export list, which is currently stored in the
>>"module-definition file" libparrot.def. However, Windows provides a
>>"nicer" way of doing this, by prefixing a declaration with
>>__declspec(dllexport) someFunction
>>Wi
At 7:57 PM +0100 5/5/04, Nicholas Clark wrote:
On Wed, May 05, 2004 at 08:59:03AM -0400, Dan Sugalski wrote:
Yeah, that's what I'm figuring. The symbols themselves should be
cross-platform, modulo the odd prefix character, or so I hope. The
linker magic is definitely going to be platform and lin
On Wed, May 05, 2004 at 08:59:03AM -0400, Dan Sugalski wrote:
> Yeah, that's what I'm figuring. The symbols themselves should be
> cross-platform, modulo the odd prefix character, or so I hope. The
> linker magic is definitely going to be platform and linker
> specific--we may have to throw in
At 7:16 PM +0200 5/5/04, Ron Blaschke wrote:
On Tue, 4 May 2004 08:34:55 -0400, Dan Sugalski wrote:
Another todo list task for the interested. A perl & linker thing.
Right now, through the wonders of the Unix default linking
conventions, every function in parrot gets exported whether we want
th
On Tue, 4 May 2004 08:34:55 -0400, Dan Sugalski wrote:
> Another todo list task for the interested. A perl & linker thing.
>
> Right now, through the wonders of the Unix default linking
> conventions, every function in parrot gets exported whether we want
> them to be or not, and generally we d
At 12:40 AM -0700 5/5/04, Jeff Clites wrote:
On May 4, 2004, at 5:34 AM, Dan Sugalski wrote:
The right way to fix this is to have a file with the acceptable
exportable symbols and a fix to the link stage to convince the
linker that it should *only* export these symbols.
I have this working locall
On May 4, 2004, at 5:34 AM, Dan Sugalski wrote:
The right way to fix this is to have a file with the acceptable
exportable symbols and a fix to the link stage to convince the linker
that it should *only* export these symbols.
I have this working locally on Mac OS X--I expect it will be rather
pl
Another todo list task for the interested. A perl & linker thing.
Right now, through the wonders of the Unix default linking
conventions, every function in parrot gets exported whether we want
them to be or not, and generally we don't. That needs fixing.
The right way to fix this is to have a f
29 matches
Mail list logo
