Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)

2004-05-24 Thread Dan Sugalski
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

Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)

2004-05-23 Thread Steve Fink
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

Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)

2004-05-15 Thread Ron Blaschke
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

Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)

2004-05-15 Thread Jeff Clites
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

Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)

2004-05-15 Thread Andy Dougherty
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

Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)

2004-05-14 Thread Ron Blaschke
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

Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)

2004-05-14 Thread Ron Blaschke
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

Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)

2004-05-14 Thread Ron Blaschke
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

Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)

2004-05-14 Thread Ron Blaschke
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

Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)

2004-05-14 Thread Andrew Dougherty
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

Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)

2004-05-14 Thread Bernhard Schmalhofer
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

Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)

2004-05-13 Thread Dan Sugalski
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

Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)

2004-05-13 Thread Dan Sugalski
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

Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)

2004-05-13 Thread Jeff Horwitz
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

Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)

2004-05-13 Thread Brent 'Dax' Royal-Gordon
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

Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)

2004-05-13 Thread Jeff Clites
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

PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)

2004-05-12 Thread Ron Blaschke
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

Re: TODO: Linker magic step for configure

2004-05-09 Thread Ron Blaschke
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

Re: TODO: Linker magic step for configure

2004-05-08 Thread Dan Sugalski
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

Re: TODO: Linker magic step for configure

2004-05-08 Thread Ron Blaschke
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

Re: TODO: Linker magic step for configure

2004-05-05 Thread Jeff Clites
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

Re: TODO: Linker magic step for configure

2004-05-05 Thread Ron Blaschke
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

Re: TODO: Linker magic step for configure

2004-05-05 Thread Dan Sugalski
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

Re: TODO: Linker magic step for configure

2004-05-05 Thread Nicholas Clark
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

Re: TODO: Linker magic step for configure

2004-05-05 Thread Dan Sugalski
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

Re: TODO: Linker magic step for configure

2004-05-05 Thread Ron Blaschke
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

Re: TODO: Linker magic step for configure

2004-05-05 Thread Dan Sugalski
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

Re: TODO: Linker magic step for configure

2004-05-05 Thread Jeff Clites
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

TODO: Linker magic step for configure

2004-05-04 Thread Dan Sugalski
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