Re: PATCH RFA: Add Go support
Ralf Wildenhues ralf.wildenh...@gmx.de writes: * Ian Lance Taylor wrote on Tue, Oct 12, 2010 at 11:42:56PM CEST: This patch adds support for the Go programming language to libtool. Go is described at http://golang.org/ . I'm not very familiar with libtool. This patch is mostly a cut-and-paste job. It is enough to let me use automake with LIBTOOL to build libraries from Go code. Do you have, or are working on, an Automake patch for Go support? I do not have an automake patch, although that is a logical next step. I've been using libtool with a Makefile.am which uses this definition: LTGOCOMPILE = $(LIBTOOL) --tag GO --mode=compile $(GCCGO) $(INCLUDES) \ $(AM_GOFLAGS) $(GOFLAGS) and then runs $(LTGOCOMPILE) as needed. Adding Go support to automake may be a little tricky as Go requires a slightly different compilation model: you must pass all files that are in the same package to the compiler at once. You can't compile them separately. The patch requires a patch which I've proposed for autoconf: http://lists.gnu.org/archive/html/autoconf-patches/2010-10/msg4.html I'm not sure how to handle a libtool patch which requires an autoconf patch. Perhaps this can not be committed until the next libtool release. We usually try to support older Autoconf as well (currently back to 2.59), so that people don't need to upgrade all at once. When only macros from Autoconf proper are missing (as opposed to macros from other third parties), they can be treated similarly to how AC_PROG_SED is treated with a backup in libtool.m4. Done. In any case I would appreciate any comments and any advice as to how to get this committed to libtool. Thanks. tests/suffix.test should be updated. Dont. Can you send output of ./libtool --tag=GO --config for Libtool with Go support enabled? You need to patch Libtool's configure.ac to enable Go support (this should be part of the patch as well). Attached. A NEWS entry would be good. Done. Testsuite additions (to the new testsuite) would be nice, like one setup where Go is the only language enabled (to verify that object and executable extension computation work etc). We can write those tests if you're not familiar with Autotest. Can you suggest a test that I can look at to see what this should look like? Updated patch attached (two patches from git format-patch, let me know if there is a better way to send this). Ian # Which release of libtool.m4 was used? macro_version=2.4.1a macro_revision=1.3300 # Assembler program. AS=as # DLL creation program. DLLTOOL=false # Object dumper program. OBJDUMP=objdump # Whether or not to build shared libraries. build_libtool_libs=yes # Whether or not to build static libraries. build_old_libs=yes # What type of objects to build. pic_mode=default # Whether or not to optimize for fast installation. fast_install=yes # Shell to use when invoking shell scripts. SHELL=/bin/sh # An echo program that protects backslashes. ECHO=printf %s\\n # The host system. host_alias= host=x86_64-unknown-linux-gnu host_os=linux-gnu # The build system. build_alias= build=x86_64-unknown-linux-gnu build_os=linux-gnu # A sed program that does not truncate output. SED=/bin/sed # Sed that helps us avoid accidentally triggering echo(1) options like -n. Xsed=$SED -e 1s/^X// # A grep program that handles long lines. GREP=/bin/grep # An ERE matcher. EGREP=/bin/grep -E # A literal string matcher. FGREP=/bin/grep -F # A BSD- or MS-compatible name lister. NM=/usr/bin/nm -B # Whether we need soft or hard links. LN_S=ln -s # What is the maximum length of a command? max_cmd_len=1572864 # Object file suffix (normally o). objext=o # Executable file suffix (normally ). exeext= # whether the shell understands unset. lt_unset=unset # turn spaces into newlines. SP2NL=tr \\040 \\012 # turn newlines into spaces. NL2SP=tr \\015\\012 \\040\\040 # convert $build file names to $host format. to_host_file_cmd=func_convert_file_noop # convert $build files to toolchain format. to_tool_file_cmd=func_convert_file_noop # Method to check whether dependent libraries are shared objects. deplibs_check_method=pass_all # Command to use when deplibs_check_method = file_magic. file_magic_cmd=\$MAGIC_CMD # How to find potential files when deplibs_check_method = file_magic. file_magic_glob= # Find potential files using nocaseglob when deplibs_check_method = file_magic. want_nocaseglob=no # Command to associate shared and link libraries. sharedlib_from_linklib_cmd=printf %s\\n # The archiver. AR=ar # Flags to create an archive. AR_FLAGS=cru # How to feed a file listing to the archiver. archiver_list_spec=@ # A symbol stripping program. STRIP=strip # Commands used to install an old-style archive. RANLIB=ranlib old_postinstall_cmds=chmod 644 \$oldlib~\$RANLIB \$oldlib old_postuninstall_cmds= # Whether to use a lock for old archive extraction. lock_old_archive_extraction=no # A C compiler. LTCC=gcc # LTCC compiler
Re: PATCH RFA: Add Go support
* Ian Lance Taylor wrote on Wed, Oct 13, 2010 at 07:31:04PM CEST: Ralf Wildenhues writes: Do you have, or are working on, an Automake patch for Go support? I do not have an automake patch, although that is a logical next step. I've been using libtool with a Makefile.am which uses this definition: LTGOCOMPILE = $(LIBTOOL) --tag GO --mode=compile $(GCCGO) $(INCLUDES) \ $(AM_GOFLAGS) $(GOFLAGS) and then runs $(LTGOCOMPILE) as needed. Adding Go support to automake may be a little tricky as Go requires a slightly different compilation model: you must pass all files that are in the same package to the compiler at once. You can't compile them separately. That is not a big problem per se. However, how would you implement build parallelism? Inside gccgo? Should it eventually have jobserver support, received from make? What if files reside in subdirs (of the current directory, or of $srcdir), will objects be created in subdirs or in the current directory (and how would we avoid creation of files below $srcdir in a VPATH build, given that $srcdir is a concept not known to the compiler a priori)? Or maybe it has no objects at all? Can the user split up large projects into multiple pieces, either by separate Makefile.am files for separate directories, or somehow separately compiling the set of sources in one directory, maybe by library or by program compiled? If the latter is to be supported, then things like overlapping sources become a problem (i.e., both libfoo and libbar use baz.o). Can you send output of ./libtool --tag=GO --config for Libtool with Go support enabled? You need to patch Libtool's configure.ac to enable Go support (this should be part of the patch as well). Attached. Thanks, that looks quite reasonable. Testsuite additions (to the new testsuite) would be nice, like one setup where Go is the only language enabled (to verify that object and executable extension computation work etc). We can write those tests if you're not familiar with Autotest. Can you suggest a test that I can look at to see what this should look like? Off-hand I don't know an ideal candidate, but you can look at template.at for a way to do it manually (by using the libtool script generated in the toplevel, and not using Automake) would give coverage of compile and link mode. For a complete configure example, you need to setup at least a minimal configure.ac, and run LT_AT_AUTOCONF, LT_AT_CONFIGURE etc. The helper macros are defined in tests/testsuite.at. For example tests/early-libtool.at uses them. Again, this is something we can probably write easily for you (just it will be until the weekend for me). Updated patch attached (two patches from git format-patch, let me know if there is a better way to send this). You can just merge them to one, for example with: git rebase -i HEAD~2 which will open a file in an editor. Replace the edit in the second line with squash, save, exit, edit the combined log entry. If you have changes in your tree to tack onto the most recent commit, you can use 'git commit -a --amend'. Both strategies assume that the amended-to commits are not published in a public git repository yet (i.e., nobody has code that depends on them exactly). But we can do this kind of fixup too. Thanks, Ralf
Re: PATCH RFA: Add Go support
Ralf Wildenhues ralf.wildenh...@gmx.de writes: * Ian Lance Taylor wrote on Wed, Oct 13, 2010 at 07:31:04PM CEST: Ralf Wildenhues writes: Do you have, or are working on, an Automake patch for Go support? I do not have an automake patch, although that is a logical next step. I've been using libtool with a Makefile.am which uses this definition: LTGOCOMPILE = $(LIBTOOL) --tag GO --mode=compile $(GCCGO) $(INCLUDES) \ $(AM_GOFLAGS) $(GOFLAGS) and then runs $(LTGOCOMPILE) as needed. Adding Go support to automake may be a little tricky as Go requires a slightly different compilation model: you must pass all files that are in the same package to the compiler at once. You can't compile them separately. That is not a big problem per se. However, how would you implement build parallelism? Inside gccgo? Should it eventually have jobserver support, received from make? Note that when I say a package I don't mean an entire program. A package in Go is like a single library, or what some languages call a module. E.g., the standard Go library has a fmt package, an os package, a math package, etc. When compiling Go, you must pass all files in a package to the compiler at the same time. In principle part of the compilation of a single package could be parallelized, but not in any simple or straightforward way. You can group many different Go packages together into a single .a or .so file. What if files reside in subdirs (of the current directory, or of $srcdir), will objects be created in subdirs or in the current directory (and how would we avoid creation of files below $srcdir in a VPATH build, given that $srcdir is a concept not known to the compiler a priori)? Or maybe it has no objects at all? Only one object file is created for each package. It can go wherever. Can the user split up large projects into multiple pieces, either by separate Makefile.am files for separate directories, or somehow separately compiling the set of sources in one directory, maybe by library or by program compiled? Sure. If the latter is to be supported, then things like overlapping sources become a problem (i.e., both libfoo and libbar use baz.o). That can not happen, because baz.go can only be in one package. Ian
[RFC] w32 and Libtool.
Hi!
I have been tinkering with a text describing the hoops to jump when
prepping a library for Windows. At some point it should be texified and
added to the manual, but I'm not the best candidate for that job so this
is plain ASCII for now.
Can you spot any errors?
(I have not actually tested the code samples. Yet)
Cheers,
Peter
Windows DLLs.
-
This topic describes a couple of ways to portably create Windows Dynamic
Link Libraries (DLLs). Libtool knows how to create DLLs using GNU tools
and using Microsoft tools.
A typical library has a hidden implementation with an interface
described in a header file. On just about every system, the interface
could be something like this:
Example foo.h:
#ifndef FOO_H
#define FOO_H
int one (void);
int two (void);
extern int three;
#endif /* FOO_H */
And the implementation could be something like this:
Example foo.c:
#include foo.h
int one (void)
{
return 1;
}
int two (void)
{
return 2;
}
int three = 3;
When using contemporary GNU tools to create the Windows DLL, the above
code will work there too, thanks to its auto-import/auto-export
features. But that is not the case when using older GNU tools or perhaps
more interesting when using proprietary tools. In those cases the code
will need additional decorations on the interface symbols with
__declspec(dllimport) and __declspec(dllexport) depending on if the
library is built or if it's consumed and how it's built and consumed.
Concentrating on how Libtool is using Microsoft tools, Libtool will dig
through the object files making up the library looking for non-static
symbols to automatically export. I.e., Libtool with Microsoft tools is
trying to mimic the auto-export feature of the contemporary GNU tools.
It should be noted that the GNU auto-export feature in turned off when
an explicit __declspec(dllexport) is seen. The GNU tools is doing this
to not make more symbols visible for projects that have already taken
the trouble to decorate all symbols. There is no similar way to limit
which symbols are visible in the code when Libtool is using Microsoft
tools. In order to limit symbol visibility in that case you need to use
one of the -export-symbols or -export-symbols-regex options.
No matching help with auto-import is provided by Libtool for neither
proprietary tools nor older GNU tools, so symbols *must* be decorated in
order to import them from a DLL for everything but contemporary GNU
tools on Windows.
When the objects that form the library are built, there are generally
two copies built for each object. One copy is used when linking the DLL
and one copy is used for the static library. On Windows systems, the
copy used when creating the DLL is compiled with the flag -DDLL_EXPORT.
It is common practice to also add a flag that is only present when the
library is built, but that will not be present when it is consumed, such
as -DBUILDING_LIBFOO. These defines are then used to discriminate how
the interface symbols should be decorated.
However, the matching double compile is not performed when consuming
libraries. It is therefore not possible to reliably distinguish if the
consumer is importing from a DLL or if it is going to use a static
library. With contemporary GNU tools, auto-import saves the day. With
Microsoft tools you typically get away with always compiling the code as
if it is going to be linked with a DLL. There are cases when this does
not work, such as when only variables and no functions are imported from
the library. There is also a price connected to this liberal use of
imports in that an extra indirection is introduced when you are
consuming the static version of the library. That extra indirection is
always present when the DLL is consumed, but it is not needed when
consuming the static library.
For older GNU tools and other proprietary tools there is no generic way
to make it possible to consume either of the DLL or the static library
without user intervention, the tools needs to be told what is intended.
Or, to be exact, the author are not aware of any generic way. One
assumption that has been used is that if a DLL is being built
(DLL_EXPORT is defined) then that DLL is going to consume any dependent
libraries as DLLs. If that assumption is made everywhere, it is possible
to select how an end user application is consuming libraries by adding a
single flag -DDLL_EXPORT when a DLL build is required. This is of course
an all or nothing deal, either everything as DLLs or everything as
static libraries.
To sum up the above, the header file of the foo library needs to be
changed into something like this:
Modified foo.h:
#ifndef FOO_H
#define FOO_H
#if (defined _WIN32 || defined _WIN32_WCE) !defined __GNUC__
# ifdef BUILDING_LIBFOO
# ifdef DLL_EXPORT
# define LIBFOO_SCOPE extern __declspec (dllexport)
# endif
# elif defined _MSC_VER || defined DLL_EXPORT
# define LIBFOO_SCOPE extern __declspec (dllimport)
# endif
#endif
#ifndef LIBFOO_SCOPE
# define LIBFOO_SCOPE
Re: [RFC] w32 and Libtool.
On Wed, 13 Oct 2010, Peter Rosin wrote:
Hi!
I have been tinkering with a text describing the hoops to jump when
prepping a library for Windows. At some point it should be texified and
added to the manual, but I'm not the best candidate for that job so this
is plain ASCII for now.
Can you spot any errors?
not an error, but a remark. See at the bottom
(I have not actually tested the code samples. Yet)
Cheers,
Peter
Windows DLLs.
-
This topic describes a couple of ways to portably create Windows Dynamic
Link Libraries (DLLs). Libtool knows how to create DLLs using GNU tools
and using Microsoft tools.
A typical library has a hidden implementation with an interface
described in a header file. On just about every system, the interface
could be something like this:
Example foo.h:
#ifndef FOO_H
#define FOO_H
int one (void);
int two (void);
extern int three;
#endif /* FOO_H */
And the implementation could be something like this:
Example foo.c:
#include foo.h
int one (void)
{
return 1;
}
int two (void)
{
return 2;
}
int three = 3;
When using contemporary GNU tools to create the Windows DLL, the above
code will work there too, thanks to its auto-import/auto-export
features. But that is not the case when using older GNU tools or perhaps
more interesting when using proprietary tools. In those cases the code
will need additional decorations on the interface symbols with
__declspec(dllimport) and __declspec(dllexport) depending on if the
library is built or if it's consumed and how it's built and consumed.
Concentrating on how Libtool is using Microsoft tools, Libtool will dig
through the object files making up the library looking for non-static
symbols to automatically export. I.e., Libtool with Microsoft tools is
trying to mimic the auto-export feature of the contemporary GNU tools.
It should be noted that the GNU auto-export feature in turned off when
an explicit __declspec(dllexport) is seen. The GNU tools is doing this
to not make more symbols visible for projects that have already taken
the trouble to decorate all symbols. There is no similar way to limit
which symbols are visible in the code when Libtool is using Microsoft
tools. In order to limit symbol visibility in that case you need to use
one of the -export-symbols or -export-symbols-regex options.
No matching help with auto-import is provided by Libtool for neither
proprietary tools nor older GNU tools, so symbols *must* be decorated in
order to import them from a DLL for everything but contemporary GNU
tools on Windows.
When the objects that form the library are built, there are generally
two copies built for each object. One copy is used when linking the DLL
and one copy is used for the static library. On Windows systems, the
copy used when creating the DLL is compiled with the flag -DDLL_EXPORT.
It is common practice to also add a flag that is only present when the
library is built, but that will not be present when it is consumed, such
as -DBUILDING_LIBFOO. These defines are then used to discriminate how
the interface symbols should be decorated.
However, the matching double compile is not performed when consuming
libraries. It is therefore not possible to reliably distinguish if the
consumer is importing from a DLL or if it is going to use a static
library. With contemporary GNU tools, auto-import saves the day. With
Microsoft tools you typically get away with always compiling the code as
if it is going to be linked with a DLL. There are cases when this does
not work, such as when only variables and no functions are imported from
the library. There is also a price connected to this liberal use of
imports in that an extra indirection is introduced when you are
consuming the static version of the library. That extra indirection is
always present when the DLL is consumed, but it is not needed when
consuming the static library.
For older GNU tools and other proprietary tools there is no generic way
to make it possible to consume either of the DLL or the static library
without user intervention, the tools needs to be told what is intended.
Or, to be exact, the author are not aware of any generic way. One
assumption that has been used is that if a DLL is being built
(DLL_EXPORT is defined) then that DLL is going to consume any dependent
libraries as DLLs. If that assumption is made everywhere, it is possible
to select how an end user application is consuming libraries by adding a
single flag -DDLL_EXPORT when a DLL build is required. This is of course
an all or nothing deal, either everything as DLLs or everything as
static libraries.
To sum up the above, the header file of the foo library needs to be
changed into something like this:
Modified foo.h:
#ifndef FOO_H
#define FOO_H
#if (defined _WIN32 || defined _WIN32_WCE) !defined __GNUC__
_WIN32 is defined also On Windows CE if __GNUC__ is not defined (i.e.
microsoft tools are used in the Windows CE case). So it can be simplified.
Vincent Torri
#
Re: [RFC] w32 and Libtool.
Hi Peter,
* Peter Rosin wrote on Wed, Oct 13, 2010 at 08:19:27PM CEST:
Can you spot any errors?
See below. I've only checked for things obvious to me; I hope somebody
else verifies the w32 semantics and details. ;-)
Thanks for writing this!
(I have not actually tested the code samples. Yet)
Thanks in advance! :-)
Windows DLLs.
-
This topic describes a couple of ways to portably create Windows Dynamic
Link Libraries (DLLs). Libtool knows how to create DLLs using GNU tools
Two spaces after period.
and using Microsoft tools.
A typical library has a hidden implementation with an interface
described in a header file. On just about every system, the interface
could be something like this:
Example foo.h:
#ifndef FOO_H
#define FOO_H
int one (void);
int two (void);
extern int three;
#endif /* FOO_H */
And the implementation could be something like this:
Example foo.c:
#include foo.h
int one (void)
{
return 1;
}
int two (void)
{
return 2;
}
int three = 3;
Isn't this less-than fully general, in the sense that having in addition
references to one and three from within two would possibly be more
complex to handle?
When using contemporary GNU tools to create the Windows DLL, the above
code will work there too, thanks to its auto-import/auto-export
features. But that is not the case when using older GNU tools or perhaps
more interesting when using proprietary tools. In those cases the code
will need additional decorations on the interface symbols with
__declspec(dllimport) and __declspec(dllexport) depending on if the
library is built or if it's consumed and how it's built and consumed.
Concentrating on how Libtool is using Microsoft tools, Libtool will dig
How about simplifying this to
With Microsoft tools, Libtool will dig ...
through the object files making up the library looking for non-static
that make up the
symbols to automatically export. I.e., Libtool with Microsoft tools is
trying to mimic the auto-export feature of the contemporary GNU tools.
It should be noted that the GNU auto-export feature in turned off when
s/ in / is /
an explicit __declspec(dllexport) is seen. The GNU tools is doing this
s/is doing/do/ or s/is/are/
to not make more symbols visible for projects that have already taken
the trouble to decorate all symbols. There is no similar way to limit
s/all// ? (because how can you know that it did do so for all symbols,
when parts of the project may come from third parties?)
which symbols are visible in the code when Libtool is using Microsoft
tools. In order to limit symbol visibility in that case you need to use
one of the -export-symbols or -export-symbols-regex options.
No matching help with auto-import is provided by Libtool for neither
proprietary tools nor older GNU tools, so symbols *must* be decorated in
order to import them from a DLL for everything but contemporary GNU
tools on Windows.
But can we not assume that older GNU tools are irrelevant? What would
keep people from updating them?
When the objects that form the library are built, there are generally
two copies built for each object. One copy is used when linking the DLL
and one copy is used for the static library. On Windows systems, the
copy used when creating the DLL is compiled with the flag -DDLL_EXPORT.
It is common practice to also add a flag that is only present when the
library is built, but that will not be present when it is consumed, such
as -DBUILDING_LIBFOO. These defines are then used to discriminate how
the interface symbols should be decorated.
This seems to be a bit reversed. From a narrative standpoint, the
common practice only appears out of necessity, and the necessity has
not been explained yet. Right?
However, the matching double compile is not performed when consuming
libraries. It is therefore not possible to reliably distinguish if the
consumer is importing from a DLL or if it is going to use a static
library. With contemporary GNU tools, auto-import saves the day.
because auto-import does what exactly?
(pointer to auto-import documentation from binutils?)
With
Microsoft tools you typically get away with always compiling the code as
if it is going to be linked with a DLL. There are cases when this does
not work, such as when only variables and no functions are imported from
the library. There is also a price connected to this liberal use of
imports in that an extra indirection is introduced when you are
consuming the static version of the library. That extra indirection is
always present when the DLL is consumed, but it is not needed when
consuming the static library.
This paragraph is fairly vague. I understand if you don't want to tell
all the gory details about this, but in that case maybe a pointer to
more detailed documentation would be good here.
For older GNU tools and other proprietary tools there is no generic way
to make it possible to consume
Re: [RFC] w32 and Libtool.
Den 2010-10-13 20:50 skrev Ralf Wildenhues:
Hi Peter,
* Peter Rosin wrote on Wed, Oct 13, 2010 at 08:19:27PM CEST:
Can you spot any errors?
See below. I've only checked for things obvious to me; I hope somebody
else verifies the w32 semantics and details. ;-)
I have snipped the hunks where I agree with you review and have nothing
of value to add. I have also taken case of the nit mentioned by Vincent.
Two spaces after period.
I consider that part of texification.
int one (void)
{
return 1;
}
int two (void)
{
return 2;
}
int three = 3;
Isn't this less-than fully general, in the sense that having in addition
references to one and three from within two would possibly be more
complex to handle?
I don't remember ever having problems with that, but I suppose two () could
be written as { return three - one (); } if that makes you sleep better.
an explicit __declspec(dllexport) is seen. The GNU tools is doing this
to not make more symbols visible for projects that have already taken
the trouble to decorate all symbols. There is no similar way to limit
s/all// ? (because how can you know that it did do so for all symbols,
when parts of the project may come from third parties?)
You have to decorate all symbols you wish to export, because if you miss
some, auto-export will have been disabled by the symbols that was indeed
decorated. I'll still remove all though, because you really only need
to decorate the symbols that you wish to export, and that is typically
not *all* symbols.
No matching help with auto-import is provided by Libtool for neither
proprietary tools nor older GNU tools, so symbols *must* be decorated in
order to import them from a DLL for everything but contemporary GNU
tools on Windows.
But can we not assume that older GNU tools are irrelevant? What would
keep people from updating them?
I don't know. I felt that a bit of history wouldn't hurt here. Maybe I'm
just muddying the waters?
When the objects that form the library are built, there are generally
two copies built for each object. One copy is used when linking the DLL
and one copy is used for the static library. On Windows systems, the
copy used when creating the DLL is compiled with the flag -DDLL_EXPORT.
It is common practice to also add a flag that is only present when the
library is built, but that will not be present when it is consumed, such
as -DBUILDING_LIBFOO. These defines are then used to discriminate how
the interface symbols should be decorated.
This seems to be a bit reversed. From a narrative standpoint, the
common practice only appears out of necessity, and the necessity has
not been explained yet. Right?
Right. I'll rephrase.
With
Microsoft tools you typically get away with always compiling the code as
if it is going to be linked with a DLL. There are cases when this does
not work, such as when only variables and no functions are imported from
the library. There is also a price connected to this liberal use of
imports in that an extra indirection is introduced when you are
consuming the static version of the library. That extra indirection is
always present when the DLL is consumed, but it is not needed when
consuming the static library.
This paragraph is fairly vague. I understand if you don't want to tell
all the gory details about this, but in that case maybe a pointer to
more detailed documentation would be good here.
I don't know where this is spelled out, and it is intentionally vague as
I don't know all the answers.
For older GNU tools and other proprietary tools there is no generic way
to make it possible to consume either of the DLL or the static library
without user intervention, the tools needs to be told what is intended.
Or, to be exact, the author are not aware of any generic way. One
s/are/is/ This sounds a bit awkward still.
Don't know what to do about that.
assumption that has been used is that if a DLL is being built
that is commonly used?
I rephrased it differently.
It should be noted that there are various projects that attempt to relax
these requirements by various low level tricks, but they are not
discussed here.
Pointers?
Added.
Here's an update:
Windows DLLs.
-
This topic describes a couple of ways to portably create Windows Dynamic
Link Libraries (DLLs). Libtool knows how to create DLLs using GNU tools
and using Microsoft tools.
A typical library has a hidden implementation with an interface
described in a header file. On just about every system, the interface
could be something like this:
Example foo.h:
#ifndef FOO_H
#define FOO_H
int one (void);
int two (void);
extern int three;
#endif /* FOO_H */
And the implementation could be something like this:
Example foo.c:
#include foo.h
int one (void)
{
return 1;
}
int two (void)
{
return three - one ();
}
int three = 3;
When using contemporary GNU tools to create the Windows DLL, the above
code will work
Re: [RFC] w32 and Libtool.
Hi Peter,
* Peter Rosin wrote on Wed, Oct 13, 2010 at 11:53:55PM CEST:
Den 2010-10-13 20:50 skrev Ralf Wildenhues:
Two spaces after period.
I consider that part of texification.
Sure.
int one (void)
{
return 1;
}
int two (void)
{
return 2;
}
int three = 3;
Isn't this less-than fully general, in the sense that having in addition
references to one and three from within two would possibly be more
complex to handle?
I don't remember ever having problems with that, but I suppose two () could
be written as { return three - one (); } if that makes you sleep better.
I don't care much, but that's the difference that exposes missing -fPIC
on GNU/Linux (non-x86) systems. Suppose that bit is irrelevant for
COFF.
an explicit __declspec(dllexport) is seen. The GNU tools is doing this
to not make more symbols visible for projects that have already taken
the trouble to decorate all symbols. There is no similar way to limit
s/all// ? (because how can you know that it did do so for all symbols,
when parts of the project may come from third parties?)
You have to decorate all symbols you wish to export, because if you miss
some, auto-export will have been disabled by the symbols that was indeed
decorated.
Right. But to me, the sentence can be read to imply that, when the user
has forgotten to decorate some symbols, then GNU tools will somehow
still magically do TRT.
Maybe an example is in order here, to explain why I stumbled over this:
you include third-party code in your project (e.g., helper functions
like those from gnulib), and that code is decorated (unlike gnulib)
but your own code is not. Boom, that's trouble, but not in the way
you intended.
I'll still remove all though, because you really only need
to decorate the symbols that you wish to export, and that is typically
not *all* symbols.
OK. That also avoids my (arguably weird) misreading.
No matching help with auto-import is provided by Libtool for neither
proprietary tools nor older GNU tools, so symbols *must* be decorated in
order to import them from a DLL for everything but contemporary GNU
tools on Windows.
But can we not assume that older GNU tools are irrelevant? What would
keep people from updating them?
I don't know. I felt that a bit of history wouldn't hurt here. Maybe I'm
just muddying the waters?
Oh, mentioning older GNU tools seems like a good idea to me; but I also
think that you can regard them as irrelevant for current libtool
operation.
With
Microsoft tools you typically get away with always compiling the code as
if it is going to be linked with a DLL. There are cases when this does
not work, such as when only variables and no functions are imported from
the library. There is also a price connected to this liberal use of
imports in that an extra indirection is introduced when you are
consuming the static version of the library. That extra indirection is
always present when the DLL is consumed, but it is not needed when
consuming the static library.
This paragraph is fairly vague. I understand if you don't want to tell
all the gory details about this, but in that case maybe a pointer to
more detailed documentation would be good here.
I don't know where this is spelled out, and it is intentionally vague as
I don't know all the answers.
OK. Maybe somebody else can fill this in, or we leave it like this for
now.
For older GNU tools and other proprietary tools there is no generic way
to make it possible to consume either of the DLL or the static library
without user intervention, the tools needs to be told what is intended.
Or, to be exact, the author are not aware of any generic way. One
s/are/is/ This sounds a bit awkward still.
Don't know what to do about that.
Well, how about let's remove the sentence starting with Or?
Here's an update:
Looks good to me, given comments above.
Thanks,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
