Support for tcc as a linker
Last year, libtool gained support for tcc as a compiler, but up to now it
didn't always work as a linker (configuring a project using:
CC=tcc LD=tcc ./configure
; if the LD=tcc setting is omitted then configure assumes that ld is
being used, diagnoses GNU ld (typically), and then fails e.g. with
--whole-archive not being supported when it tries to link by running tcc
(which does not call ld, but does its own linking).
The attached patch against current git HEAD adds tcc support on Linux in
the non-GNU ld section _LT_LINKER_SHLIBS. I guess it could be added for
other kernels that tcc supports, but I'm not sure what they are, nor how to
add the support without unfortunate duplication (the logic seems to be set
up to assume either gcc or a system compiler).
At present, tcc can't be treated like GNU ld, because it doesn't understand
--{no,}-whole-archive, though there is a patch for that from some years ago
which I'm going to see if I can fix up.'
With my attached libtool.m4 patch, I am able to build and run FontForge,
which is ~500kLOC of C dating from all parts of the last 14 years, using
tcc and libtool git HEAD. I'd say that's quite impressive for both tcc and
libtool! (My motivation is to have a quicker build, which tcc certainly
gives.)
--
http://rrt.sc3d.org
From 10695a219fe0de117a72a3408ee5f1f12409fd56 Mon Sep 17 00:00:00 2001
From: Reuben Thomas r...@sc3d.org
Date: Thu, 31 Jul 2014 15:32:13 +0100
Subject: [PATCH] libtool.m4: add support for tcc as linker
---
m4/libtool.m4 | 10 ++
1 file changed, 10 insertions(+)
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 320d8b3..91b460e 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -5515,6 +5515,16 @@ _LT_EOF
_LT_TAGVAR(link_all_deplibs, $1)=yes
;;
+linux*)
+ case $cc_basename in
+ tcc*)
+ # Fabrice Bellard et al's Tiny C Compiler
+ _LT_TAGVAR(ld_shlibs, $1)=yes
+ _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
+ esac
+ ;;
+
netbsd*)
if echo __ELF__ | $CC -E - | $GREP __ELF__ /dev/null; then
_LT_TAGVAR(archive_cmds, $1)='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags' # a.out
--
1.9.1
Add dynamic export support for tcc
The attached patch adds support for tcc's -rdynamic, the equivalent of GNU ld's -Wl,--export-dynamic. -- http://rrt.sc3d.org From 33d504492e36cb875d15c12515a2ab6b160931f6 Mon Sep 17 00:00:00 2001 From: Reuben Thomas r...@sc3d.org Date: Thu, 31 Jul 2014 16:53:58 +0100 Subject: [PATCH] Add dynamic export support for tcc --- m4/libtool.m4 | 3 +++ 1 file changed, 3 insertions(+) diff --git a/m4/libtool.m4 b/m4/libtool.m4 index 91b460e..6c6b2f2 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -5015,6 +5015,9 @@ _LT_EOF fi case $cc_basename in +tcc*) + _LT_TAGVAR(export_dynamic_flag_spec, $1)='-rdynamic' + ;; xlf* | bgf* | bgxlf* | mpixlf*) # IBM XL Fortran 10.1 on PPC cannot create shared libs itself _LT_TAGVAR(whole_archive_flag_spec, $1)='--whole-archive$convenience --no-whole-archive' -- 1.9.1
Historically-derived confusion in libtool manual
Section 9.4 Unresolved dlopen problems is a bit confusing because in fact all the problems mentioned are solved by libltdl. Since libltdl is supplied with libtool, I'm not sure how it's useful to continue to describe these problems, at least in this way. There are some other historical knots in the documentation: On some platforms, whose dynamic linkers are too limited for a simple implementation of `libltdl' services, it requires GNU DLD, yet if you go to the GNU DLD page, it says it has been deprecated in favour of libtool. Also, in section 9.2 of the libtool manual, there are references to a type and variable which are declared in ltdl.h, before libltdl has even been mentioned. I wonder if it might be worth removing section 9 of the manual, incorporating whatever bits continue to be useful as technical footnotes to section 10? Then, programmers are encouraged to use the most high-level and advanced features of libtool (i.e. libltdl) first, rather than finding their way there via the older features; or at least reverse the order of these two sections, so that readers learn about libltdl first. -- http://rrt.sc3d.org/ | impossible, a. worth doing ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Avoiding compiler warnings/errors with function pointers
On Tue, 5 Jun 2007, Peter O'Gorman wrote: freeBSD has a dlfunc() function that behaves like dlsym but returns a function pointer, last time I looked it was implemented using a union... wait, let me look again...: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/lib/libc/gen/dlfunc.c?rev=1.3;content-type=text%2Fplain I think it is even in our TODO to have libltdl do this somehow, in the meantime, Reuben can do something similar in his own code. I am on Linux, where I can't see a similar function. -- http://rrt.sc3d.org/ | think tank, n. a safe container for noxious gases ___ http://lists.gnu.org/mailman/listinfo/libtool
Avoiding compiler warnings/errors with function pointers
I have a line of code like this:
if ((l_fn = lt_dlsym(l_st-lth, ladspa_descriptor)) == NULL) {
where l_fn is a function pointer. gcc says:
ladspa.c: In function 'sox_ladspa_getopts':
ladspa.c:114: warning: ISO C forbids assignment between function pointer and
'void *'
There's no problem with this on my machine with my compiler settings, but if
I wanted to write strictly conforming ISO C it looks like I'd have a
problem; equally if I wanted this code to run on a machine where void * was
not compatible with a function pointer.
Is there some way to avoid this problem?
--
http://rrt.sc3d.org/ | resident, a. unable to leave (Bierce)
___
http://lists.gnu.org/mailman/listinfo/libtool
Typo in 1.5.22 manual, Libltdl interface section
`lt_dlforeachfile' returns value returned by the last call made to FUNC. missing the before value. -- http://rrt.sc3d.org/ | The yak is slow but the earth is patient (LucasArts) ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
lt_dlforeachfile
I'm a bit unclear on what I can expect about the filenames passed to the callback. I'm using libtool 1.5.22 and whatever libltdtl that comes with, and have found that it seems to pass basenames, suitable for use with lt_dlopenext, but the documentation is unclear on whether I can rely on this behaviour; it seems quite sensible, since each module in a directory typically comes in static and dynamic flavours and a bunch of links, and I wouldn't want to get passed every single filename. Either way, the documentation could use some clarification on this point, unless I've misread it. -- http://rrt.sc3d.org/ | certain, a. insufficiently analysed ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking automatically with dlopen
On Wed, 18 Apr 2007, Bob Friesenhahn wrote: Years ago, I converted ImageMagick to use loadable modules in order to decouple from optional libraries. This did require a clean codec interface but it turned out fine. There are 95 modules, and libldtl is only used if the package is built to use loadable modules. A module loader was developed to keep track of loadable modules. Each module has load/unload routines and registers itself with the library by invoking a module adding function in the main library. Thanks for the tips. I've had a look at the ImageMagick sources, which presumably (and seemingly) still use your scheme, and the good news (for me) is that it looks like I can do what I want without changing my existing modules (which already have a clean interface). Still, it would be nice if it could be done fully automatically, something like: libtool --mode=link --dlopenlink=foo,bar,baz ... If -lfoo, -lbar or -lbaz appears in the command line, the relevant library is not linked against. Instead, a dummy module will be compiled that contains two functions: one that that attempts to open the library and resolves the relevant symbols, which is called on program startup, and another which returns a value saying whether the given library was successfully opened. [Inessential features: it would be nice if the initialisation functions could be called automatically; if not, they could be called by a libtool initialisation function, which means that the total code impact would be just a few lines: #include ltdl.h ... lt_dlinit(); lt_dlautoopen(); ... which has the advantage that the programmer can choose when to take the (in general potentially large) hit of doing the dlopening. It would also be nice if the program could easily test whether an individual symbol had been resolved by testing whether or not it was NULL.] It seems to me that this could be implemented relatively easily: first, call the linker normally, then find out which libraries (if any) in the dlopenlink link have been pulled in, then scan the object to discover which symbols from each library have been imported; generate and compile the appropriate stub, and then perform the link again, without the relevant libraries, but with the stub. I admit that this buys me very little in my particular case: it seems that I can indeed get away with a little build system hackery and merely change the module that knows about all the CODEC and effect modules in SoX. That's nice to learn, and it's probably what I'll do. I'm interested, though, to know whether the general case is worth solving. Perhaps it's not: maybe if your program is dependent on a particular library in lots of places, then you simply have to link against it. I suspect, however, that the same considerations employed to justify aspect-oriented programming could be used to justify the idea that a library could be used in many places in a program (i.e. hard to isolate in the way that ImageMagick or SoX can isolate transforming functions) and yet happily be present or not without making the program break down. It would have to involve a large number of API calls (or you can just proxy them) as well as a large number of modules from which they are called. -- http://rrt.sc3d.org/ | Psalms 19:12 -- tagline for the guilty ___ http://lists.gnu.org/mailman/listinfo/libtool
Typo in 1.5.22's info manual
Both macros define the shell variables LIBLTDL, to the link flag that you should use to link with libltdl, and LTDLINCL, to the preprocessor flag that you should use to compile with programs that include `ltdl.h'. It is up to you to use `AC_SUBST' to ensure that this variable will be available in `Makefile's... It looks like there are two variables to deal with here, so in the last sentence, this variable should be these variables. -- http://rrt.sc3d.org/ memoir, n. a lie that flatters the author's ego and the reader's intellect ___ Bug-libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Linking automatically with dlopen
On Tue, 17 Apr 2007, Ralf Wildenhues wrote: If you can find out the set of libraries at 'configure' time, then there is no need for dlopen. There is in my case: I do know the set of libraries at configure time, but I can't link against all of them. The particular case I have in mind is building a Debian package that can go in main but use libraries that are not distributed in main. I can't link normally against such libraries (as that would make the package depend on them, and a package in main can't depend on a package not in main). Doing this fully automatically does not work on any system I know of. AIX in some cases allows startup with some symbols not yet defined, but that's pretty obscure. I don't think it works with libs that may or may not be present, though. I don't want symbols to be undefined at startup, I want something (the linker? libtool?) to convert symbol references into indirect references via pointers initialised at runtime by libdl/libltdl. The use I have in mind is linking CODECs with different licenses into an application without needing to change the code so that the CODECs are dlopened. Then, if certain CODECs are not available, the application can simply give an error message if the user attempts to use them, but the application author doesn't need to write (or in this case, re-write) the code to use dlopen. This is the typical application for dlopen/lt_dlopen. Indeed, but I'd rather not have to rewrite modules into this form by hand, in particular because for other uses the code can be linked normally, and I don't want to depend on libdl/libltdl if I can avoid it. (The code I have in mind is SoX (sox.sf.net).) -- http://rrt.sc3d.org/ | taciturn, n. a silent pot ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking automatically with dlopen
On Sun, 15 Apr 2007, Bob Friesenhahn wrote: On Mon, 16 Apr 2007, Reuben Thomas wrote: Is there a way to use libtool to link against a library using dlopen? I want to be able to link against a library which may not be present at runtime, be certain that the application starts up (i.e. the dynamic linker doesn't discover that a library is missing and abort), and then be able to find out whether a given library was successfully linked or not (and hence decide whether I can execute code that uses symbols from that library). This is a function of libltdl, which comes with libtool. I use it in GraphicsMagick. I read the documentation for libltdl before posting originally, but I couldn't see how to do what I wanted. Can you explain, please? In particular, I couldn't see how to link using libltdl instead of the normal linker without changing my source. -- http://rrt.sc3d.org/ | think tank, n. a safe container for noxious gases ___ http://lists.gnu.org/mailman/listinfo/libtool
Linking automatically with dlopen
Is there a way to use libtool to link against a library using dlopen? I want to be able to link against a library which may not be present at runtime, be certain that the application starts up (i.e. the dynamic linker doesn't discover that a library is missing and abort), and then be able to find out whether a given library was successfully linked or not (and hence decide whether I can execute code that uses symbols from that library). (I'm not quite clear, but perhaps doing this fully automatically is beyond the scope of libtool and needs linker support?) The use I have in mind is linking CODECs with different licenses into an application without needing to change the code so that the CODECs are dlopened. Then, if certain CODECs are not available, the application can simply give an error message if the user attempts to use them, but the application author doesn't need to write (or in this case, re-write) the code to use dlopen. If this isn't possible, is there a tool I can use to dlopen-ify my code for a particular library or list of symbols or include file or similar? I guess if none of this is possible then the easiest way may be to rewrite the application's CODEC interface so that CODEC wrappers are themselves shared objects which can be dlopened, which avoids rewriting the CODEC wrappers. Then a failure to link a given CODEC wrapper when it is dlopened indicates won't stop the application running. -- http://rrt.sc3d.org/ Any technology distinguishable from magic is insufficiently advanced (Keeling) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problem with default builds on mingw32
On Mon, 8 Jan 2007, Ralf Wildenhues wrote: Hello Reuben, * Reuben Thomas wrote on Wed, Jan 03, 2007 at 12:04:37AM CET: libtool 1.5.22 contains the following (trivial) code and (non-trivial) comments: # It is impossible to link a dll without this setting, and # we shouldn't force the makefile maintainer to figure out # which system we are compiling for in order to pass an extra # flag for every libtool invocation. # allow_undefined=no # FIXME: Unfortunately, there are problems with the above when trying # to make a dll which has undefined symbols, in which case not # even a static library is built. For now, we need to specify # -no-undefined on the libtool link line when we can be certain # that all symbols are satisfied, otherwise we get a static library. allow_undefined=yes Unfortunately, this breaks the default case on mingw32/msys (tested with mingw 5.1.2, msys 1.0.10, i.e. current stable), because the objects are first built to go into a DLL, hence symbols have _imp_ prefixes, then the static library is made from the objects (because allow_undefined has been set to yes), then when the static library is linked the linker complains that it can't find any symbols in the library (because it's not expecting the _imp_ prefixes, as it's a static library). Uncommenting allow_undefined=no and commenting allow_undefined=yes in the above makes it work. Does that mean if you put -no-undefined into the link flags then things work? Yes. If yes, then please do that. But this means that mingw users need to do something special. libtool still needs fixing. The current behaviour never works; the previous behaviour works in some cases. It would seem that the obvious thing to do is fix libtool so that allow_undefined=yes works on mingw, i.e. if allow_undefined=yes then compile for static linking, not for dynamic linking. -- http://rrt.sc3d.org/ | Slow Pedestrian Crossing (Anon) ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Problem with default builds on mingw32
libtool 1.5.22 contains the following (trivial) code and (non-trivial) comments: # It is impossible to link a dll without this setting, and # we shouldn't force the makefile maintainer to figure out # which system we are compiling for in order to pass an extra # flag for every libtool invocation. # allow_undefined=no # FIXME: Unfortunately, there are problems with the above when trying # to make a dll which has undefined symbols, in which case not # even a static library is built. For now, we need to specify # -no-undefined on the libtool link line when we can be certain # that all symbols are satisfied, otherwise we get a static library. allow_undefined=yes Unfortunately, this breaks the default case on mingw32/msys (tested with mingw 5.1.2, msys 1.0.10, i.e. current stable), because the objects are first built to go into a DLL, hence symbols have _imp_ prefixes, then the static library is made from the objects (because allow_undefined has been set to yes), then when the static library is linked the linker complains that it can't find any symbols in the library (because it's not expecting the _imp_ prefixes, as it's a static library). Uncommenting allow_undefined=no and commenting allow_undefined=yes in the above makes it work. I'm guessing that the fix was made for some other platform which has a similar problem in the reverse direction; perhaps more platform-specific intelligence is required here? I was trying to build SoX (http://sox.sf.net/) from current CVS, with automake 1.9.6, libtool 1.5.22 and autoconf 2.61, but from what I can see the problem is not dependent on the source being built. I configured and attempted to build with ./configure make. -- http://rrt.sc3d.org/ | mediate, v.i. to butt in (Bierce) ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
