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
Conditional building of Modules
Hi,
I have been having problems with building modules to be installed
into pkglibdir automatically, but I have been having problems using
pkglib_LTLIBRARIES and EXTRA_LTLIBRARIES to work together. Instead I
have been using lib_LTLIBRARIES and EXTRA_LTLIBRARIES and setting rpath.
However the problem I have now is that it isn't the modules in the
right place. The modules are being installed into /usr/local/lib
instead of /usr/local/lib/mpg123. I have managed to solve the problem
by having each module compiled in a seperate directory, and
conditionally building the SUBDIRS, however I would rather not do it
this way as there is only a single source file per module.
Does anyone have a working recipe for doing this sort of thing?
Thanks,
nick.
MODULE_LIST=mod_coreaudio.la mod_dummy.la mod_jack.la
PKGLIBDIR=/usr/local/lib/mpg123
Makefile.am
=
lib_LTLIBRARIES = @MODULE_LIST@
EXTRA_LTLIBRARIES = \
mod_coreaudio.la \
mod_dummy.la \
mod_jack.la \
mod_portaudio.la \
mod_pulse.la
mod_coreaudio_la_SOURCES = coreaudio.c
mod_coreaudio_la_LDFLAGS = -module -rpath @PKGLIBDIR@ \
-framework AudioToolbox \
-framework AudioUnit \
-framework CoreServices
mod_dummy_la_SOURCES = dummy.c
mod_dummy_la_LDFLAGS = -module -rpath @PKGLIBDIR@
mod_pulse_la_SOURCES = pulse.c
mod_pulse_la_CFLAGS = @PULSE_CFLAGS@
mod_pulse_la_LDFLAGS = -module -rpath @PKGLIBDIR@ @PULSE_LDFLAGS@
mod_pulse_la_LIBADD = @PULSE_LIBS@
mod_jack_la_SOURCES = jack.c
mod_jack_la_CFLAGS = @JACK_CFLAGS@
mod_jack_la_LDFLAGS = -module -rpath @PKGLIBDIR@ @JACK_LDFLAGS@
mod_jack_la_LIBADD = @JACK_LIBS@
mod_portaudio_la_SOURCES = portaudio.c
mod_portaudio_la_LDFLAGS = -module -rpath @PKGLIBDIR@
mod_portaudio_la_LIBADD = -lportaudio
Result of Running make install
test -z /usr/local/lib || mkdir -p -- /usr/local/lib
/bin/sh ../libtool --mode=install /sw/bin/ginstall -c
'mod_coreaudio.la' '/usr/local/lib/mod_coreaudio.la'
/sw/bin/ginstall -c .libs/mod_coreaudio.0.0.0.so /usr/local/lib/
mod_coreaudio.0.0.0.so
(cd /usr/local/lib { ln -s -f mod_coreaudio.0.0.0.so mod_coreaudio.
0.so || { rm -f mod_coreaudio.0.so ln -s mod_coreaudio.0.0.0.so
mod_coreaudio.0.so; }; })
(cd /usr/local/lib { ln -s -f mod_coreaudio.0.0.0.so
mod_coreaudio.so || { rm -f mod_coreaudio.so ln -s mod_coreaudio.
0.0.0.so mod_coreaudio.so; }; })
/sw/bin/ginstall -c .libs/mod_coreaudio.lai /usr/local/lib/
mod_coreaudio.la
libtool: install: warning: remember to run `libtool --finish /usr/
local/lib/mpg123'
/bin/sh ../libtool --mode=install /sw/bin/ginstall -c
'mod_portaudio.la' '/usr/local/lib/mod_portaudio.la'
/sw/bin/ginstall -c .libs/mod_portaudio.0.0.0.so /usr/local/lib/
mod_portaudio.0.0.0.so
(cd /usr/local/lib { ln -s -f mod_portaudio.0.0.0.so mod_portaudio.
0.so || { rm -f mod_portaudio.0.so ln -s mod_portaudio.0.0.0.so
mod_portaudio.0.so; }; })
(cd /usr/local/lib { ln -s -f mod_portaudio.0.0.0.so
mod_portaudio.so || { rm -f mod_portaudio.so ln -s mod_portaudio.
0.0.0.so mod_portaudio.so; }; })
/sw/bin/ginstall -c .libs/mod_portaudio.lai /usr/local/lib/
mod_portaudio.la
libtool: install: warning: remember to run `libtool --finish /usr/
local/lib/mpg123'
/bin/sh ../libtool --mode=install /sw/bin/ginstall -c 'mod_jack.la'
'/usr/local/lib/mod_jack.la'
/sw/bin/ginstall -c .libs/mod_jack.0.0.0.so /usr/local/lib/mod_jack.
0.0.0.so
(cd /usr/local/lib { ln -s -f mod_jack.0.0.0.so mod_jack.0.so ||
{ rm -f mod_jack.0.so ln -s mod_jack.0.0.0.so mod_jack.0.so; }; })
(cd /usr/local/lib { ln -s -f mod_jack.0.0.0.so mod_jack.so ||
{ rm -f mod_jack.so ln -s mod_jack.0.0.0.so mod_jack.so; }; })
/sw/bin/ginstall -c .libs/mod_jack.lai /usr/local/lib/mod_jack.la
libtool: install: warning: remember to run `libtool --finish /usr/
local/lib/mpg123'
/bin/sh ../libtool --mode=install /sw/bin/ginstall -c 'mod_dummy.la'
'/usr/local/lib/mod_dummy.la'
/sw/bin/ginstall -c .libs/mod_dummy.0.0.0.so /usr/local/lib/mod_dummy.
0.0.0.so
(cd /usr/local/lib { ln -s -f mod_dummy.0.0.0.so mod_dummy.0.so ||
{ rm -f mod_dummy.0.so ln -s mod_dummy.0.0.0.so mod_dummy.0.so; }; })
(cd /usr/local/lib { ln -s -f mod_dummy.0.0.0.so mod_dummy.so ||
{ rm -f mod_dummy.so ln -s mod_dummy.0.0.0.so mod_dummy.so; }; })
/sw/bin/ginstall -c .libs/mod_dummy.lai /usr/local/lib/mod_dummy.la
libtool: install: warning: remember to run `libtool --finish /usr/
local/lib/mpg123'
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Conditional building of Modules
On Wed, Apr 18, 2007 at 03:54:13PM +0100, Nicholas J Humfrey wrote: I have been having problems with building modules to be installed into pkglibdir automatically, but I have been having problems using pkglib_LTLIBRARIES and EXTRA_LTLIBRARIES to work together. Instead I have been using lib_LTLIBRARIES and EXTRA_LTLIBRARIES and setting rpath. However the problem I have now is that it isn't the modules in the right place. The modules are being installed into /usr/local/lib instead of /usr/local/lib/mpg123. I have managed to solve the problem by having each module compiled in a seperate directory, and conditionally building the SUBDIRS, however I would rather not do it this way as there is only a single source file per module. Does anyone have a working recipe for doing this sort of thing? I conditionally build modules with various dependences according to which of them are available and install them under pkglibdir -- and build many in a single directory. However, I do not experience any of the described problems so maybe in fact I do something else than you... Anyway, you can have a look at http://gwyddion.svn.sourceforge.net/viewvc/gwyddion/trunk/gwyddion/modules/file/Makefile.am?view=markup Yeti -- http://gwyddion.net/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Conditional building of Modules
Aha, so your not using EXTRA_LTLIBRARIES at all. I quite liked having a string list of modules to be built, but perhaps I will have a go at using Automake Conditionals instead. Thanks for your reply, nick. On 18 Apr 2007, at 16:51, David Nečas (Yeti) wrote: On Wed, Apr 18, 2007 at 03:54:13PM +0100, Nicholas J Humfrey wrote: I have been having problems with building modules to be installed into pkglibdir automatically, but I have been having problems using pkglib_LTLIBRARIES and EXTRA_LTLIBRARIES to work together. Instead I have been using lib_LTLIBRARIES and EXTRA_LTLIBRARIES and setting rpath. However the problem I have now is that it isn't the modules in the right place. The modules are being installed into /usr/local/lib instead of /usr/local/lib/mpg123. I have managed to solve the problem by having each module compiled in a seperate directory, and conditionally building the SUBDIRS, however I would rather not do it this way as there is only a single source file per module. Does anyone have a working recipe for doing this sort of thing? I conditionally build modules with various dependences according to which of them are available and install them under pkglibdir -- and build many in a single directory. However, I do not experience any of the described problems so maybe in fact I do something else than you... Anyway, you can have a look at http://gwyddion.svn.sourceforge.net/viewvc/gwyddion/trunk/gwyddion/ modules/file/Makefile.am?view=markup Yeti -- http://gwyddion.net/ ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: .exe magic
[added libtool to CC list] Corinna Vinschen wrote: On Apr 18 04:49, Charles Wilson wrote: The current .exe behavior has benefited from many years of tweaking and fine-tuning, across many different packages (cygwin, gcc, gdb, binutils, automake, autoconf, libtool, bash, coreutils, ...) to work together to give the current, mostly coherent, least-surprise behavior we enjoy today. [...] Apart from that, I don't like what libtool does. I think it's a terrible idea to have a script and a binary with the same name (only differing by the .exe suffix) in the same directory. This behaviour breaks the CYGWIN=transparent_exe option and there's no reliable way around this. Is there any chance that this could be changed in libtool? Absolutely. I outlined the steps necessary to do this: http://cygwin.com/ml/cygwin-apps/2006-03/msg00028.html But got not P to TC. Any takers this time around? Caveat: over a year after the message referenced above, but libtool2.0 is STILL in code-slush, so the desired fixes will have to wait until after 2.0 (or 2.2, or whatever the heck we decide to call it) is released. Of the three steps outlined in the fix, it's possible that (1) and (2) could go in prior to the 2.0/2.2 release, but this kind of thinking is why we're still in slush and haven't released. -- Chuck P.S. This will make you cry: libtool-1.5.0 was released 14-Apr-2003, four years ago last Saturday. After a year and a half, some destabilizing changes were under consideration and rejected for 2.0 -- we were too close to a release -- so an abortive branch-2-0 was created 3-Oct-2004 and the destabilizing changes went into HEAD. Development continued sporadically on this branch for about a year until 24-Aug-2005 -- but throughout, most development effort remained on the trunk or branch-1-5. The load on the developers maintaining three branches was extreme, and branch-2-0 -- supposedly the almost ready to release branch -- was getting short shrift, for a YEAR. And the destabilized HEAD was now actually *more* stable than branch-2-0! It got so bad that the branch was abandoned, and 2.0 was retargeted to come from cvs HEAD Real Soon Now. Another year and a half, and here we are...still in code slush. (Sounds very very similar to the ongoing discussions with regards to gcc-4.2: http://gcc.gnu.org/ml/gcc/2007-02/msg00427.html and http://gcc.gnu.org/ml/gcc/2007-04/msg00510.html. Only much much worse.) However, there are indications that this situation will come to an end Real Soon Now And This Time We Mean It. So, here's hoping... ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Conditional building of Modules
* Nicholas J Humfrey wrote on Wed, Apr 18, 2007 at 04:54:13PM CEST: I have been having problems with building modules to be installed into pkglibdir automatically, but I have been having problems using pkglib_LTLIBRARIES and EXTRA_LTLIBRARIES to work together. Instead I have been using lib_LTLIBRARIES and EXTRA_LTLIBRARIES and setting rpath. Sounds good to me. Try this (AC_SUBST(MODULE_LIST), and use $(pkglibdir) which is provided for you). lib_LTLIBRARIES = @MODULE_LIST@ With this line you're lying to automake -- it should be pkglib_LTLIBRARIES. FWIW, please note that -framework is specific to darwin (I guess you knew that). Hope that helps. Cheers, Ralf configure.ac: AC_INIT(mpg123,1,[EMAIL PROTECTED]) AM_INIT_AUTOMAKE(foreign) AC_PROG_CC AC_PROG_LIBTOOL MODULE_LIST=mod_coreaudio.la mod_dummy.la mod_jack.la AC_SUBST(MODULE_LIST) AC_CONFIG_FILES(Makefile) AC_OUTPUT Makefile.am: pkglib_LTLIBRARIES = @MODULE_LIST@ EXTRA_LTLIBRARIES = \ mod_coreaudio.la \ mod_dummy.la \ mod_jack.la \ mod_portaudio.la \ mod_pulse.la mod_coreaudio_la_SOURCES = coreaudio.c mod_coreaudio_la_LDFLAGS = -module -rpath $(pkglibdir) \ -framework AudioToolbox \ -framework AudioUnit \ -framework CoreServices mod_dummy_la_SOURCES = dummy.c mod_dummy_la_LDFLAGS = -module mod_pulse_la_SOURCES = pulse.c mod_pulse_la_CFLAGS = @PULSE_CFLAGS@ mod_pulse_la_LDFLAGS = -module -rpath $(pkglibdir) @PULSE_LDFLAGS@ mod_pulse_la_LIBADD = @PULSE_LIBS@ mod_jack_la_SOURCES = jack.c mod_jack_la_CFLAGS = @JACK_CFLAGS@ mod_jack_la_LDFLAGS = -module -rpath $(pkglibdir) @JACK_LDFLAGS@ mod_jack_la_LIBADD = @JACK_LIBS@ mod_portaudio_la_SOURCES = portaudio.c mod_portaudio_la_LDFLAGS = -module -rpath $(pkglibdir) mod_portaudio_la_LIBADD = -lportaudio ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool dll creation (mingw32 undefined symbols)
Hello Richard, * richard wrote on Tue, Apr 17, 2007 at 11:18:24PM CEST: I'd like to start slow by just crosscompile a executable and a dynamic library, but i fail at building the .dll with libtool complaining about libtool: link: warning: undefined symbols not allowed in i586-pc-mingw32msvc shared libraries [...] The --no-undefined is set for the library, Typo: -no-undefined (just one leading hyphen). i would be very thankful for an simple howto or demo program which accomplishes what i am trying to do. I took a look at the libltdl sources, because they compile perfectly as a dll, but did not manage to get much out of it. Look at the mdemo test sources, that's a test that uses libltdl. Is that a little better? AC_C_CONST FWIW, I don't think you need AC_C_CONST nowadays. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
[cygwin, libtool] use shell function to emit wrapper scripts and wrapper.exe source [Was: Re: .exe magic]
[Added libtool-patches to CC list. Discussion of this patch
should probably drop libtool and cygwin]
Ralf Wildenhues wrote:
* Charles Wilson wrote on Wed, Apr 18, 2007 at 08:49:31PM CEST:
Caveat: over a year after the message referenced above, but libtool2.0
is STILL in code-slush, so the desired fixes will have to wait until
after 2.0
... I'd prefer to see such a patch before deciding when it's good to put
it in.
Okay, here's the first bit. It's pretty simple. Testing is in progress
(and in conjuction with the new argz fix I just posted to
libtool-patches), but looks good so far: the new wrapper scripts are
identical to old ones generated without this patch.
--
Chuck
ChangeLog
2007-04-18 Charles Wilson [EMAIL PROTECTED]
* libltdl/config/ltmain.m4sh [func_mode_link]: move wrapper
script writing from here...
[func_emit_libtool_wrapper_script]: to this new function, and
write to stdout
[func_mode_link]: move cwrapper source code writing from here...
[func_emit_libtool_cwrapperexe_source]: to this new function,
and write to stdout
[func_mode_link]: call the two new functions and redirect to
appropriate file.
Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.72
diff -u -r1.72 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 10 Apr 2007 19:09:26 - 1.72
+++ libltdl/config/ltmain.m4sh 19 Apr 2007 01:05:30 -
@@ -1202,6 +1202,555 @@
}
}
+# func_emit_libtool_wrapper_script
+# emit a libtool wrapper script on stdout
+# don't directly open a file because we may want to
+# incorporate the script contents within a cygwin/mingw
+# wrapper executable. Must ONLY be called from within
+# func_mode_link because it depends on a number of variable
+# set therein.
+func_emit_libtool_wrapper_script ()
+{
+ $ECHO \
+#! $SHELL
+
+# $output - temporary wrapper script for $objdir/$outputname
+# Generated by $PROGRAM (GNU $PACKAGE$TIMESTAMP) $VERSION
+#
+# The $output program cannot be directly executed until all the libtool
+# libraries that it depends on are installed.
+#
+# This wrapper script should never be moved out of the build directory.
+# If it is, it will not operate correctly.
+
+# Sed substitution that helps us do robust quoting. It backslashifies
+# metacharacters that are still active within double-quoted strings.
+Xsed='${SED} -e 1s/^X//'
+sed_quote_subst='$sed_quote_subst'
+
+# Be Bourne compatible
+if test -n \\${ZSH_VERSION+set}\ (emulate sh) /dev/null 21; then
+ emulate sh
+ NULLCMD=:
+ # Zsh 3.x and 4.x performs word splitting on \${1+\[EMAIL PROTECTED]},
which
+ # is contrary to our usage. Disable this feature.
+ alias -g '\${1+\[EMAIL PROTECTED]}'='\[EMAIL PROTECTED]'
+ setopt NO_GLOB_SUBST
+else
+ case \`(set -o) 2/dev/null\` in *posix*) set -o posix;; esac
+fi
+BIN_SH=xpg4; export BIN_SH # for Tru64
+DUALCASE=1; export DUALCASE # for MKS sh
+
+# The HP-UX ksh and POSIX shell print the target directory to stdout
+# if CDPATH is set.
+(unset CDPATH) /dev/null 21 unset CDPATH
+
+relink_command=\$relink_command\
+
+# This environment variable determines our operation mode.
+if test \\$libtool_install_magic\ = \$magic\; then
+ # install mode needs the following variables:
+ generated_by_libtool_version='$macro_version'
+ notinst_deplibs='$notinst_deplibs'
+else
+ # When we are sourced in execute mode, \$file and \$ECHO are already set.
+ if test \\$libtool_execute_magic\ != \$magic\; then
+ECHO=\$qecho\
+file=\\$0\
+# Make sure echo works.
+if test \X\$1\ = X--no-reexec; then
+ # Discard the --no-reexec flag, and continue.
+ shift
+elif test \X\`{ \$ECHO '\t'; } 2/dev/null\`\ = 'X\t'; then
+ # Yippee, \$ECHO works!
+ :
+else
+ # Restart under the correct shell, and then maybe \$ECHO will work.
+ exec $SHELL \\$0\ --no-reexec \${1+\[EMAIL PROTECTED]}
+fi
+ fi\
+
+ $ECHO \
+
+ # Find the directory that this script lives in.
+ thisdir=\`\$ECHO \X\$file\ | \$Xsed -e 's%/[^/]*$%%'\`
+ test \x\$thisdir\ = \x\$file\ thisdir=.
+
+ # Follow symbolic links until we get to the real thisdir.
+ file=\`ls -ld \\$file\ | ${SED} -n 's/.*- //p'\`
+ while test -n \\$file\; do
+destdir=\`\$ECHO \X\$file\ | \$Xsed -e 's%/[^/]*\$%%'\`
+
+# If there was a directory component, then change thisdir.
+if test \x\$destdir\ != \x\$file\; then
+ case \\$destdir\ in
+ [/]* | [A-Za-z]:[/]*) thisdir=\\$destdir\ ;;
+ *) thisdir=\\$thisdir/\$destdir\ ;;
+ esac
+fi
+
+file=\`\$ECHO \X\$file\ | \$Xsed -e 's%^.*/%%'\`
+file=\`ls -ld \\$thisdir/\$file\ | ${SED} -n 's/.*- //p'\`
+ done
+
+ # Try to get the absolute directory name.
+ absdir=\`cd \\$thisdir\ pwd\`
+ test -n \\$absdir\ thisdir=\\$absdir\
+
+
+ if test $fast_install = yes; then
+
Re: mdemo ltdl failure
Charles Wilson wrote: Charles Wilson wrote: Charles Wilson wrote: I'll whip up a patch and post it to the newlib list. So, I posted the following: http://sourceware.org/ml/newlib/2007/msg00271.html However, there's no telling how long it'll be before a new cygwin kernel is released that includes the patch, and besides, libtool ought to work on current and reasonably recent cygwin kernels. So, how should libtool address this issue in the interim? Always use libltdl's argz stuff on cygwin, until further notice: version check on uname, etc etc? If so, how do we induce that Here's my attempt: [snip long description of ugly runtime test] See http://lists.gnu.org/archive/html/libtool-patches/2007-03/msg00030.html After discussion with Bob F, I've reimplemented this fix without the actual runtime test. Instead, if $host_os is cygwin, and cygwin version is 1.5.24 or older, then force use of libltdl builtin argz. In all other cases (including cross), pre-existing detection rules apply. This is because the test is just too ugly for words, not to mention brittle. Trying to tease out malloc issues outside of a dedicated malloc testsuite is just plain silly. I'm still using the -export-symbols-regex .* fix for libmlib in tests/mdemo -- it's also included in this patch. Still true. TESTING: I've tested this under the following conditions: (1) broken cygwin kernel (1.5.24-2 used, but any older would do) --detects failure, builds successfully using libltdl's argz --resultant libraries also work after dropping in a fixed cygwin kernel. (2) fixed cygwin kernel (official snapshot from 20070330) --detects success, builds successfully using system argz --resultant libraries coredump if you drop in a broken cygwin kernel after the fact. This is expected: broken cygwin is broken precisely because its argz facility coredumps on argz_insert(). (3) fixed cygwin kernel, but with $lt_cv_sys_argz_works=no. --does not even try to run the test program, and successfully builds using libltdl's argz --resultant libraries works fine even after dropping in a broken cygwin kernel. Re-ran all of these tests under the specified conditions. Same results as the original patch. (4) linux (whose system argz is OK) --detects success, builds using system argz, works. (5) linux, but with $lt_cv_sys_argz_works=no. --doesn't run the test, and builds using libltdl argz. works. (6) mingw, which doesn't have any system argz facility at all --the test is not run --builds successfully with libltdl's argz Did not run these tests. configury and sourcecode paths unchanged from original path so these should obviously still work. But I'll retest if desired. New Changelog: 2007-03-17 Charles Wilson [EMAIL PROTECTED] * libltdl/argz_.h: ensure error_t definition is obtained in same mechanism system argz.h would have. * libltdl/libltdl/lt__glibc.h: also detect if SYSTEM_ARGZ_IS_BROKEN when determining whether to re#def argz* functions. * libltdl/m4/argz.m4: add new test to check if $host's argz facilities are known bad. * tests/mdemo/Makefile.am: -export-symbols-regex fix for libmlib. -- Chuck Index: libltdl/argz_.h === RCS file: /cvsroot/libtool/libtool/libltdl/argz_.h,v retrieving revision 1.6 diff -u -r1.6 argz_.h --- libltdl/argz_.h 4 Sep 2006 17:23:30 - 1.6 +++ libltdl/argz_.h 17 Mar 2007 06:09:46 - @@ -32,6 +32,8 @@ #define LT__ARGZ_H 1 #include stdlib.h +#define __need_error_t +#include errno.h #include sys/types.h #if defined(LTDL) Index: libltdl/libltdl/lt__glibc.h === RCS file: /cvsroot/libtool/libtool/libltdl/libltdl/lt__glibc.h,v retrieving revision 1.7 diff -u -r1.7 lt__glibc.h --- libltdl/libltdl/lt__glibc.h 26 Oct 2006 20:39:04 - 1.7 +++ libltdl/libltdl/lt__glibc.h 17 Mar 2007 06:09:49 - @@ -37,7 +37,7 @@ # include config.h #endif -#if !defined(HAVE_ARGZ_H) +#if !defined(HAVE_ARGZ_H) || defined(SYSTEM_ARGZ_IS_BROKEN) /* Redefine any glibc symbols we reimplement to import the implementations into our lt__ namespace so we don't ever clash with the system library if our clients use argz_* Index: libltdl/m4/argz.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/argz.m4,v retrieving revision 1.3 diff -u -r1.3 argz.m4 --- libltdl/m4/argz.m4 25 Mar 2006 11:05:02 - 1.3 +++ libltdl/m4/argz.m4 17 Mar 2007 06:09:50 - @@ -27,6 +27,38 @@ ARGZ_H= AC_CHECK_FUNCS([argz_append argz_create_sep argz_insert argz_next \ argz_stringify], [], [ARGZ_H=argz.h; AC_LIBOBJ([argz])]) + +dnl if have system argz functions, allow forced use of +dnl libltdl-supplied implementation (and default to
Re: mdemo ltdl failure
On Wed, 18 Apr 2007, Charles Wilson wrote: [snip long description of ugly runtime test] See http://lists.gnu.org/archive/html/libtool-patches/2007-03/msg00030.html After discussion with Bob F, I've reimplemented this fix without the actual runtime test. Instead, if $host_os is cygwin, and cygwin version is 1.5.24 or older, then force use of libltdl builtin argz. In all other cases (including cross), pre-existing detection rules apply. This new version is certainly more attractive than before. Presumably this special case can be safely removed after enough time has elapsed for the majority of Cygwin installs to be updated. Is the: libmlib_la_LDFLAGS = -no-undefined -export-symbols-regex .* statement portable? Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
[cygwin, libtool] use shell function to emit wrapper scripts and wrapper.exe source [Was: Re: .exe magic]
[Added libtool-patches to CC list. Discussion of this patch
should probably drop libtool and cygwin]
Ralf Wildenhues wrote:
* Charles Wilson wrote on Wed, Apr 18, 2007 at 08:49:31PM CEST:
Caveat: over a year after the message referenced above, but libtool2.0
is STILL in code-slush, so the desired fixes will have to wait until
after 2.0
... I'd prefer to see such a patch before deciding when it's good to put
it in.
Okay, here's the first bit. It's pretty simple. Testing is in progress
(and in conjuction with the new argz fix I just posted to
libtool-patches), but looks good so far: the new wrapper scripts are
identical to old ones generated without this patch.
--
Chuck
ChangeLog
2007-04-18 Charles Wilson [EMAIL PROTECTED]
* libltdl/config/ltmain.m4sh [func_mode_link]: move wrapper
script writing from here...
[func_emit_libtool_wrapper_script]: to this new function, and
write to stdout
[func_mode_link]: move cwrapper source code writing from here...
[func_emit_libtool_cwrapperexe_source]: to this new function,
and write to stdout
[func_mode_link]: call the two new functions and redirect to
appropriate file.
Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.72
diff -u -r1.72 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 10 Apr 2007 19:09:26 - 1.72
+++ libltdl/config/ltmain.m4sh 19 Apr 2007 01:05:30 -
@@ -1202,6 +1202,555 @@
}
}
+# func_emit_libtool_wrapper_script
+# emit a libtool wrapper script on stdout
+# don't directly open a file because we may want to
+# incorporate the script contents within a cygwin/mingw
+# wrapper executable. Must ONLY be called from within
+# func_mode_link because it depends on a number of variable
+# set therein.
+func_emit_libtool_wrapper_script ()
+{
+ $ECHO \
+#! $SHELL
+
+# $output - temporary wrapper script for $objdir/$outputname
+# Generated by $PROGRAM (GNU $PACKAGE$TIMESTAMP) $VERSION
+#
+# The $output program cannot be directly executed until all the libtool
+# libraries that it depends on are installed.
+#
+# This wrapper script should never be moved out of the build directory.
+# If it is, it will not operate correctly.
+
+# Sed substitution that helps us do robust quoting. It backslashifies
+# metacharacters that are still active within double-quoted strings.
+Xsed='${SED} -e 1s/^X//'
+sed_quote_subst='$sed_quote_subst'
+
+# Be Bourne compatible
+if test -n \\${ZSH_VERSION+set}\ (emulate sh) /dev/null 21; then
+ emulate sh
+ NULLCMD=:
+ # Zsh 3.x and 4.x performs word splitting on \${1+\[EMAIL PROTECTED]},
which
+ # is contrary to our usage. Disable this feature.
+ alias -g '\${1+\[EMAIL PROTECTED]}'='\[EMAIL PROTECTED]'
+ setopt NO_GLOB_SUBST
+else
+ case \`(set -o) 2/dev/null\` in *posix*) set -o posix;; esac
+fi
+BIN_SH=xpg4; export BIN_SH # for Tru64
+DUALCASE=1; export DUALCASE # for MKS sh
+
+# The HP-UX ksh and POSIX shell print the target directory to stdout
+# if CDPATH is set.
+(unset CDPATH) /dev/null 21 unset CDPATH
+
+relink_command=\$relink_command\
+
+# This environment variable determines our operation mode.
+if test \\$libtool_install_magic\ = \$magic\; then
+ # install mode needs the following variables:
+ generated_by_libtool_version='$macro_version'
+ notinst_deplibs='$notinst_deplibs'
+else
+ # When we are sourced in execute mode, \$file and \$ECHO are already set.
+ if test \\$libtool_execute_magic\ != \$magic\; then
+ECHO=\$qecho\
+file=\\$0\
+# Make sure echo works.
+if test \X\$1\ = X--no-reexec; then
+ # Discard the --no-reexec flag, and continue.
+ shift
+elif test \X\`{ \$ECHO '\t'; } 2/dev/null\`\ = 'X\t'; then
+ # Yippee, \$ECHO works!
+ :
+else
+ # Restart under the correct shell, and then maybe \$ECHO will work.
+ exec $SHELL \\$0\ --no-reexec \${1+\[EMAIL PROTECTED]}
+fi
+ fi\
+
+ $ECHO \
+
+ # Find the directory that this script lives in.
+ thisdir=\`\$ECHO \X\$file\ | \$Xsed -e 's%/[^/]*$%%'\`
+ test \x\$thisdir\ = \x\$file\ thisdir=.
+
+ # Follow symbolic links until we get to the real thisdir.
+ file=\`ls -ld \\$file\ | ${SED} -n 's/.*- //p'\`
+ while test -n \\$file\; do
+destdir=\`\$ECHO \X\$file\ | \$Xsed -e 's%/[^/]*\$%%'\`
+
+# If there was a directory component, then change thisdir.
+if test \x\$destdir\ != \x\$file\; then
+ case \\$destdir\ in
+ [/]* | [A-Za-z]:[/]*) thisdir=\\$destdir\ ;;
+ *) thisdir=\\$thisdir/\$destdir\ ;;
+ esac
+fi
+
+file=\`\$ECHO \X\$file\ | \$Xsed -e 's%^.*/%%'\`
+file=\`ls -ld \\$thisdir/\$file\ | ${SED} -n 's/.*- //p'\`
+ done
+
+ # Try to get the absolute directory name.
+ absdir=\`cd \\$thisdir\ pwd\`
+ test -n \\$absdir\ thisdir=\\$absdir\
+
+
+ if test $fast_install = yes; then
+
Re: mdemo ltdl failure
Bob Friesenhahn wrote: On Wed, 18 Apr 2007, Charles Wilson wrote: [snip long description of ugly runtime test] See http://lists.gnu.org/archive/html/libtool-patches/2007-03/msg00030.html After discussion with Bob F, I've reimplemented this fix without the actual runtime test. Instead, if $host_os is cygwin, and cygwin version is 1.5.24 or older, then force use of libltdl builtin argz. In all other cases (including cross), pre-existing detection rules apply. This new version is certainly more attractive than before. Presumably this special case can be safely removed after enough time has elapsed for the majority of Cygwin installs to be updated. Right, give or take a year. 8-P Is the: libmlib_la_LDFLAGS = -no-undefined -export-symbols-regex .* statement portable? (1) Yes (2) and it shouldn't be in this patch anyway. Ralf already applied that bit to HEAD: http://www.mail-archive.com/libtool-patches@gnu.org/msg02848.html My bigger worries with this patch were that it could regress on some other, unrelated platform. I've checked the systems I have access to now, and all seem to do fine. So I have applied the change as below. This is what happens when you try some home-grown version of patch-quilt...long story. -- Chuck
Re: [cygwin, libtool] use shell function to emit wrapper scripts and wrapper.exe source [Was: Re: .exe magic]
Charles Wilson wrote: Okay, here's the first bit. It's pretty simple. Testing is in progress (and in conjuction with the new argz fix I just posted to libtool-patches), but looks good so far: the new wrapper scripts are identical to old ones generated without this patch. Test results -- old tests: == All 115 tests passed (9 tests were not run) --- gcc-3.4.5 doesn't supply gfortran, only g77. == Test results -- new tests. Unexpected failures: 14: Java convenience archives FAILED (convenience.at:273) 16: Link order of deplibs. FAILED (link-order2.at:129) 49: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:42) are actually not unexpected on cygwin. And certainly have nothing to do with this patch. Actually, I think this is may be the best test conformance I've ever seen on cygwin... -- Chuck
