Support for tcc as a linker

2014-07-31 Thread Reuben Thomas
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

Add dynamic export support for tcc

2014-07-31 Thread Reuben Thomas
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

Historically-derived confusion in libtool manual

2007-11-16 Thread Reuben Thomas
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

Re: Avoiding compiler warnings/errors with function pointers

2007-06-11 Thread Reuben Thomas
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...:

Avoiding compiler warnings/errors with function pointers

2007-06-05 Thread Reuben Thomas
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

Typo in 1.5.22 manual, Libltdl interface section

2007-05-03 Thread Reuben Thomas
`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

lt_dlforeachfile

2007-05-03 Thread Reuben Thomas
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

Re: Linking automatically with dlopen

2007-04-19 Thread Reuben Thomas
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

Typo in 1.5.22's info manual

2007-04-19 Thread Reuben Thomas
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

Re: Linking automatically with dlopen

2007-04-18 Thread Reuben Thomas
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

Re: Linking automatically with dlopen

2007-04-16 Thread Reuben Thomas
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

Linking automatically with dlopen

2007-04-15 Thread Reuben Thomas
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

Re: Problem with default builds on mingw32

2007-01-08 Thread Reuben Thomas
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

Problem with default builds on mingw32

2007-01-03 Thread Reuben Thomas
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