Re: GNU Automake 1.10.1 released -- bug #516 is still there
On Tue, 22 Jan 2008, Ralf Wildenhues wrote: I'm pleased to announce the release of Automake 1.10.1. Automake is a tool Very good, BUT more than a year ago I filed a bug report (automake#516), after sending an email some month earlier: automake generated Makefiles install manpages from the source tree in preference to those from the build tree together with a tiny and IMHO uncontroversial patch solving this problem. I am terribly disappointed that I never got any reaction and that this bug is still present in the new release. regards Peter Breitenlohner <[EMAIL PROTECTED]> ___ http://lists.gnu.org/mailman/listinfo/libtool
linking with extern DLLs under Cygwin
Hi,
I would like to make a patch to build php under Cygwin, but there is one
problem with libtool.
When you pass to it the option -l, it search only libraries of
type lib*
to check that /lib/lib.dll.a exists (interface to dll). So it
doesn't want to link
with icu libraries because when you install icu libraries, in lib directory
you have only
dll file (cyg.dll) but no dll interface static library
(lib.dll.a).
Today it is possible to link directly with dll file without static interface
library to this dll,
so I did a patch to search libraries of type "cyg.dll",
"lib.dll" or
".dll" when you use option -l under cygwin. (I have
added search
of ".dll" because of ldflags returned by icu-config :
$ ./icu-config --ldflags
-lpthread -lm -L/home/C82DHAN/tools/icu/3.8-org/lib -lcygicuin38
-lcygicuuc38 -lcygicudt38 -lpthread -lm
)
I have already post this patch on [EMAIL PROTECTED] but there is no
response ???
( http://lists.gnu.org/archive/html/libtool-patches/2007-12/msg6.html )
Regards
Denis
PS: maybe icu installation should produce this kind of library and there
would be no problem
with libtool but not all the tools use libtool to produce their dll so when
you use this previous tools
there is only cyg.dll or lib.dll library file. (and no
lib.dll.a)
Index: libtool.m4
===
RCS file: /sources/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.130
diff -u -r1.130 libtool.m4
--- libtool.m4 16 Jan 2008 14:49:40 - 1.130
+++ libtool.m4 21 Jan 2008 22:12:33 -
@@ -2088,6 +2088,7 @@
finish_cmds=
finish_eval=
shlibpath_var=
+shlib_search_prefix='lib$name'
shlibpath_overrides_runpath=unknown
version_type=none
dynamic_linker="$host_os ld.so"
@@ -2212,6 +2213,7 @@
# Cygwin DLLs use 'cyg' prefix rather than 'lib'
soname_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release}
| $
SED -e 's/[[.]]/-/g'`${versuffix}${shared_ext}'
sys_lib_search_path_spec="/usr/lib /lib/w32api /lib /usr/local/lib"
+ shlib_search_prefix='lib$name cyg$name $name'
;;
mingw*)
# MinGW DLLs use traditional 'lib' prefix
@@ -2232,6 +2234,7 @@
pw32*)
# pw32 DLLs use 'pw' prefix rather than 'lib'
library_names_spec='`echo ${libname} | sed -e 's/^lib/pw/'``echo
${releas
e} | $SED -e 's/[[.]]/-/g'`${versuffix}${shared_ext}'
+ shlib_search_prefix='lib$name pw$name $name'
;;
esac
;;
Index: ltmain.m4sh
===
RCS file: /sources/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.96
diff -u -r1.96 ltmain.m4sh
--- ltmain.m4sh 14 Jan 2008 22:06:00 - 1.96
+++ ltmain.m4sh 21 Jan 2008 22:13:27 -
@@ -5637,9 +5637,12 @@
esac
fi
if test -n "$a_deplib" ; then
- libname=`eval "\\$ECHO \"$libname_spec\""`
+ eval libnames=\"$shlib_search_prefix\"
for i in $lib_search_path $sys_lib_search_path
$shlib_search_pat
h; do
- potential_libs=`ls $i/$libname[.-]* 2>/dev/null`
+ potential_libs=""
+ for libname in $libnames; do
+ potential_libs="$potential_libs `ls $i/$libname[.-]*
2>/dev/
null`"
+ done
for potent_lib in $potential_libs; do
# Follow soft links.
if ls -lLd "$potent_lib" 2>/dev/null |
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: linking with extern DLLs under Cygwin
On Tue, Jan 22, 2008 at 10:40:43AM +0100, Denis Chancogne wrote: > Hi, > > I would like to make a patch to build php under Cygwin, but there is one > problem with libtool. > > When you pass to it the option -l, it search only libraries of > type lib* > to check that /lib/lib.dll.a exists (interface to dll). So it > doesn't want to link > with icu libraries because when you install icu libraries, in lib directory > you have only > dll file (cyg.dll) but no dll interface static library > (lib.dll.a). > > Today it is possible to link directly with dll file without static interface > library to this dll, > so I did a patch to search libraries of type "cyg.dll", > "lib.dll" or > ".dll" when you use option -l under cygwin. (I have > added search > of ".dll" because of ldflags returned by icu-config : > > $ ./icu-config --ldflags > -lpthread -lm -L/home/C82DHAN/tools/icu/3.8-org/lib -lcygicuin38 > -lcygicuuc38 -lcygicudt38 -lpthread -lm > > ) > > I have already post this patch on [EMAIL PROTECTED] but there is no > response ??? > ( http://lists.gnu.org/archive/html/libtool-patches/2007-12/msg6.html ) > > Regards > Denis > PS: maybe icu installation should produce this kind of library and there > would be no problem > with libtool but not all the tools use libtool to produce their dll so when > you use this previous tools > there is only cyg.dll or lib.dll library file. (and no > lib.dll.a) This patch breaks it for users of $libname_spec, a variable you have simply removed without notice. It may also break with older tools that do not support linking directly with dlls (but I don't know when that support was added and therefore I don't know if it is a relevant argument). It is not terribly hard to create those import libraries semi- manually. dlltool can do most of the work. Is that not an option for you? Cheers, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: linking with extern DLLs under Cygwin
Peter Rosin wrote: > It is not terribly hard to create those import libraries semi- > manually. dlltool can do most of the work. Is that not an > option for you? That or simply a symlink libfoo.dll.a -> ../bin/cygfoo-n.dll. In the official Cygwin distro all devel packages contain import libs, so I'd consider this a bug in the ICU package if it can't generate one. One can be created as a side effect of linking the DLL simply by adding -Wl,-out-implib,libfoo.dll.a. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool finding wrong version of library
Thanks for your suggestion Peter. That didn't seem to make a difference assuming that having the new libtool first in the PATH would cause it to be used in the build. I'll wait until 1.5.26 is available and try again. -- john Peter O'Gorman wrote: John Cartwright wrote: Hello All, I'm using libtool 1.5.22 on a RHEL 5 64-bit system. My problem is that libtool seems to be picking up an older 32-bit version of a library rather than the newer 64-bit version that I need. I've tried putting the correct one first in the LD_LIBRARY_PATH, but that doesn't seem to help. Can someone suggest a way that I can influence libtool's behavior on this? Hi John, Using libtool-1.5.24 will probably help you, see the recent thread 'bi-arch build problem: cannot build 64-bit libs on ppc64' for more. Thanks, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
