PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
Ron Blaschke
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 following macros will be provided in the Makefile
CFLAGS_COMMON common compiler flags
LDFLAGS_COMMON common linker flags
xxx_STATIC_BUILD cflags and ldflags to build static parrot
xxx_STATIC_USE cflags and ldflags to use static parrot
PARROT_STATIC_NAME full, platform dependent name of static parrot lib
xxx_DYNAMIC_BUILD cflags and ldflags to build shared parrot
xxx_DYNAMIC_USE cflags and ldflags to use shared parrot
PARROT_DYNAMIC_NAME full, platform dependent name of dynamic parrot lib
LDFLAGS_DYNAMIC_USE should contain "-lparrot" or "parrot.lib", or whatever
necessary, so no need to use PARROT_xxx_NAME to specify linkage
The name of the parrot library should blend into the current system (and
might even be different for debug builds, eg libparrot_g.so (is that
correct?) or parrotd.lib).
- When building / using a shared parrot the compiler macro
PARROT_LIB_DYNAMIC will be defined, for static PARROT_LIB_STATIC
- When building parrot the compiler macro PARROT_LIB_EXPORTS will be
defined, when using parrot PARROT_LIB_IMPORTS
- Symbols that should be exported are declared as
PARROT_API some_function
The include files will be grepped for them, and stored in a file xxx_api
(even on platforms that don't need it). It will look something like this:
----
# Do not edit this file!
# It is generated automatically by xxx
Parrot_new
Parrot_init
----
This file may be processed and used for linker input, to export only the
symbols mentioned. But this is platform dependent.
The definition of PARROT_API is also platform dependent (I've already
presented it for win32-generic-cl), and should go into api.h.
- The platform names are normalized to
<OS>-<architecture>-<compiler>. Hmm, should the architecture go first?
(cf PLATFORMS)
Examples are:
linux-ppc-gcc3.2.3
cygwin-x86-gcc3.3.3
win32-x86-cl13.10.3077
Platform specifics will be stored in
config/gen/platform/
generic/generic/generic any OS, any architecture, any compiler
win32/x86/generic win32, x86, any compiler
win32/generic/cl win32, any, MS compiler
win32/x86/cl win32, x86, MS compiler
linux/ppc/gcc linux, PPC, GCC
...
Possible would even be a future extension like:
win32/x86/cl13.10 win32, x86, MS compiler version > 13.10
Ron
Jeff Clites
> 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 following macros will be provided in the Makefile
> CFLAGS_COMMON common compiler flags
> LDFLAGS_COMMON common linker flags
> xxx_STATIC_BUILD cflags 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 xxx_LIB_STATIC_BUILD
(I'm worried that xxx_STATIC_BUILD by itself isn't clear.)
> xxx_STATIC_USE cflags and ldflags to use static parrot
How about:
xxx_STATIC_LINK
> PARROT_STATIC_NAME full, platform dependent name of static parrot lib
How about:
LIBPARROT_STATIC
(That's "LIB" to make it clear that this is the lib and not the
executable-linked-statically, and "name" is kind of implied.)
> xxx_DYNAMIC_BUILD cflags and ldflags to build shared parrot
> xxx_DYNAMIC_USE cflags and ldflags to use shared parrot
> PARROT_DYNAMIC_NAME full, platform dependent name of dynamic parrot lib
As above.
> LDFLAGS_DYNAMIC_USE should contain "-lparrot" or "parrot.lib", or
> whatever
> necessary, so no need to use PARROT_xxx_NAME to specify linkage
"USE" seems odd to me, though I don't right of have an alternative
which is clear.
> - 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 library, I believe. Maybe
this is not the case for Windows?
> - When building parrot the compiler macro PARROT_LIB_EXPORTS will be
> defined, when using parrot PARROT_LIB_IMPORTS
Again, for what use?
I'm not against these last 2 sets of macros--just wondering what the
intended use is.
> - Symbols that should be exported are declared as
> PARROT_API some_function
> The include files will be grepped for them, and stored in a file
> xxx_api
> (even on platforms that don't need it). It will look something like
> this:
Alternatively, we could just parse embed.h -- all and only symbols
defined there should be exported. (I believe that's the plan.)
JEff
Brent 'Dax' Royal-Gordon
> 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
for an example of such a file.
--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Jeff Horwitz
> > - 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 library, I believe. Maybe
> this is not the case for Windows?
if you're building a shared library, you need to compiler to produce
position independent (relocatable) code, which can be enabled with
compiler switches (e.g. -fPIC).
-jeff
Dan Sugalski
>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 for an example of such a file.
Well... sorta.
In addition to the symbols we export for embedders, we need to export
symbols that PMC classes, extensions, and opcode libraries may need.
(Appropriately prefixed, of course) Anything that can be dynamically
loaded needs to have its parrot symbols available.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Dan Sugalski
[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 building a static v. dynamic library, I
>believe. Maybe this is not the case for Windows?
Well, there's the potential for -PIC and a few other things you might
want on for dynamic libraries that you wouldn't for static ones,
though I expect that on most platforms there won't be a difference.
Can't hurt to have them split out to start with.
Bernhard Schmalhofer
> 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 building a static v. dynamic library, I believe. Maybe
>> this is not the case for Windows?
>
Hi,
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?
CU, Bernhard
--
**************************************************
Bernhard Schmalhofer
Senior Developer
Biomax Informatics AG
Lochhamer Str. 11
82152 Martinsried, Germany
Tel: +49 89 895574-839
Fax: +49 89 895574-825
eMail: Bernhard.S...@biomax.com
Website: www.biomax.com
**************************************************
Andrew Dougherty
> 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 a year and a half ago
-- it's # 18319, and it included some (but certainly not all) of your good
ideas.
In particular, I was careful to distinguish among three separate
functions:
Compiler: Used to turn .c files into .o files.
Linker: Used to combine .o files (and libraries) into an
executable.
Shared Library Builder: Tool to turn .o files into a shared
library. I called it by the Configure variable 'ld',
but better names are certainly welcome.
Each one of these tools needs its own set of flags.
I gather parrot's now trying to include stuff compiled with C++, so you'll
also need a macro for that. Furhter, if parrot's going to include stuff
compiled with C++, the "Linker" will have to be a command that correctly
handles C and C++. On Unix systems, that's probably just the C++
compiler. I don't know what it is on Windows or VMS.
Regarding C++ flags, I'd hope that the C++ compiler would accept the same
flags as the C compiler, but you ought to allow for the possibility of
setting extra c++ -specific flags, so you'll need a macro for that too.
> - The following macros will be provided in the Makefile
> CFLAGS_COMMON common compiler flags
> LDFLAGS_COMMON common linker flags
> xxx_STATIC_BUILD cflags and ldflags to build static parrot
> xxx_STATIC_USE cflags and ldflags to use static parrot
> PARROT_STATIC_NAME full, platform dependent name of static parrot lib
> xxx_DYNAMIC_BUILD cflags and ldflags to build shared parrot
> xxx_DYNAMIC_USE cflags and ldflags to use shared parrot
> PARROT_DYNAMIC_NAME full, platform dependent name of dynamic parrot lib
> The name of the parrot library should blend into the current system (and
> might even be different for debug builds, eg libparrot_g.so (is that
> correct?) or parrotd.lib).
For perl5, the direction we went with this issue was to embed the
different build information into the directory, rather than into the
library name. That way, you don't have to change all the command lines
that might link to parrot from -lparrot to -lparrot_g or -lparrot_64 or
-lparrot_mt or -lparrot_longdouble or -lparrot_whatever. Keeping multiple
versions of a parrot shared library on a system at the same time is
tricky, and needs to be very carefully thought out.
--
Andy Dougherty doug...@lafayette.edu
Ron Blaschke
> 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 stuff compiled with C++, so you'll
> also need a macro for that. Furhter, if parrot's going to include stuff
> compiled with C++, the "Linker" will have to be a command that correctly
> handles C and C++. On Unix systems, that's probably just the C++
> compiler. I don't know what it is on Windows or VMS.
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++?
(just didn't manage to take a grip on that thought)
>> The name of the parrot library should blend into the current system (and
>> might even be different for debug builds, eg libparrot_g.so (is that
>> correct?) or parrotd.lib).
>
> For perl5, the direction we went with this issue was to embed the
> different build information into the directory, rather than into the
> library name. That way, you don't have to change all the command lines
[...]
Good enough for me. I'd say we stick with the regular names.
Ron Blaschke
>> xxx_STATIC_BUILD cflags 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 xxx_LIB_STATIC_BUILD
> (I'm worried that xxx_STATIC_BUILD by itself isn't clear.)
xxx_LIB_STATIC_BUILD is fine with me.
>> xxx_STATIC_USE cflags and ldflags to use static parrot
> How about: xxx_STATIC_LINK
I was more thinking along the line of "building the library" (..._BUILD)
and "using the library" (..._USE).
>> PARROT_STATIC_NAME full, platform dependent name of static parrot lib
> How about: LIBPARROT_STATIC
Agreed.
>> - 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 library, I believe. Maybe
> this is not the case for Windows?
Dan has already read my thoughts on that, and posted them.
>> - When building parrot the compiler macro PARROT_LIB_EXPORTS will be
>> defined, when using parrot PARROT_LIB_IMPORTS
> Again, for what use?
> I'm not against these last 2 sets of macros--just wondering what the
> intended use is.
It's used to let the compiler know that the mentioned symbols are
exported/imported. The two macros will probably only be used to get the
PARROT_API macro, for those platforms that use it, right. Eg, Microsoft
uses "__declspec(dllimport) void someFunction()" to let the compiler know
that someFunction should be imported from a DLL. Maybe other compilers
have a similar kludge.
So, here's the new complete list of things. Hope you like it.
Makefile
CFLAGS_COMMON common compiler flags
LDFLAGS_COMMON common linker flags
CFLAGS_LIB_STATIC_BUILD cflags to build static parrot
LDFLAGS_LIB_STATIC_BUILD lflags to build static parrot
CFLAGS_LIB_STATIC_USE cflags to use static parrot
LDFLAGS_LIB_STATIC_USE lflags to use static parrot
LIBPARROT_STATIC full, platform dependent name of static parrot
lib
CFLAGS_LIB_DYNAMIC_BUILD cflags to build dynamic parrot
LDFLAGS_LIB_DYNAMIC_BUILD lflags to build dynamic parrot
CFLAGS_LIB_DYNAMIC_USE cflags to use dynamic parrot
LDFLAGS_LIB_DYNAMIC_USE lflags to use dynamic parrot
LIBPARROT_DYNAMIC full, platform dependent name of dynamic parrot
lib
C
PARROT_LIB_STATIC compiling for static parrot
PARROT_LIB_DYNAMIC compiling for dynamic parrot
PARROT_LIB_EXPORTS export parrot symbols (compiling parrot lib)
PARROT_LIB_IMPORT import parrot symbols (using parrot lib)
PARROT_API declare as API
Ron
Ron Blaschke
> 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 are facing, but focus
on UNIXisch operating systems. IIRC, these tools create a bunch of shell
scripts, glued together by m4. I'd rather stick to something that scares
me a little less.
Ron
Ron Blaschke
>> 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 might need different
> libraries for c versus c++. For example, the Solaris c++ man page has this note:
> By default, the CC driver passes the following -l options to ld:
> -lC -lC_mtstubs -lm -lw -lcx -lc
> There are likely other issues too, but that's the first one that comes to mind.
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 things wrong here?
Ron
Jeff Clites
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.
Seemingly, on Unix-ish platforms at least, using 'c++' for the linker
for everything (even for just C code) has worked so far for parrot, but
this might not always be the case. As Andy indicated, I think what this
ultimately does (for some cases) is call 'ld' with a few extra
libraries to link against.
JEff
Ron Blaschke
>> 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 things wrong here?
> 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.
> Seemingly, on Unix-ish platforms at least, using 'c++' for the linker
> for everything (even for just C code) has worked so far for parrot, but
> this might not always be the case. As Andy indicated, I think what this
> ultimately does (for some cases) is call 'ld' with a few extra
> libraries to link against.
Thanks to you guys for clearing things up for me. Seems like life is
a little more complicated than I thought.
Would it be a good idea to add those additional flags directly to the
corresponding CFLAGS_xxx and LFLAGS_xxx? Then we should also skip the
xxx_COMMON flags and also put them in those sets. Any opinions?
Ron
Steve Fink
>
> 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
C++-compatible linker even if you aren't including any C++ code. By
default, many C linkers will not allow C++ exceptions to propagate
through their stack frames. Unwinding the stack for an exception
requires some additional information stored in the stack frames.
I had to compile my own version of perl for my day job code, since we
are writing in C++ and embedding the Perl interpreter, and if C++
calls perl calls C++ throws an exception, then I need the outer C++
try block to catch the exception.
Dan Sugalski
>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
>C++-compatible linker even if you aren't including any C++ code. By
>default, many C linkers will not allow C++ exceptions to propagate
>through their stack frames. Unwinding the stack for an exception
>requires some additional information stored in the stack frames.
It probably does. We ought to allow for using a C++ aware linker to
link parrot, since we may be embedded in a C++ program.