Re: mdemo ltdl failure

2007-04-18 Thread Charles Wilson

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

2007-04-18 Thread Bob Friesenhahn

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]

2007-04-18 Thread Charles Wilson

[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

2007-04-18 Thread Charles Wilson

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]

2007-04-18 Thread Charles Wilson

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




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 
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

2007-04-18 Thread Nicholas J Humfrey

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

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

2007-04-18 Thread Nicholas J Humfrey

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

2007-04-18 Thread Charles Wilson

[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

2007-04-18 Thread Ralf Wildenhues
* 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: Linking automatically with dlopen

2007-04-18 Thread Ralf Wildenhues
* Reuben Thomas wrote on Wed, Apr 18, 2007 at 03:31:38PM CEST:
 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.

Then I don't see any other way except for (lt_)dlopening them.  Sorry.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool


Re: libtool dll creation (mingw32 undefined symbols)

2007-04-18 Thread Ralf Wildenhues
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]

2007-04-18 Thread Charles Wilson

[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
+