libtool: make prefix install fails
I'm trying to build RPMS for Swarm (www.swarm.org) on a RH8.0 system. I
am having trouble with a problem that is similar to a libtool problem
that came up almost one year ago and we discussed it in the RPM list as
well as libtool and Swarm lists.
With libtool 1.4.2, rpm/libtool would fail to build libraries properly
if the prefix for make install was different from the final install
prefix and some relinking had to be done. That broke rpm building in
RH7.2, as I recall. Or was it RH7.1? WHichever was released around
Nov.2001. Libtool was patched on November 15, 2001, and I built rpms
for that patched libtool and since then I had no trouble building rpms
on RH 7.2 and RH7.3. These are the ones I was using:
http://lark.cc.ku.edu/~pauljohn/software/libtool-20011121-1pj.i386.rpm
http://lark.cc.ku.edu/~pauljohn/software/libtool-libs-20011121-1pj.i386.rpm
I thought this shared library problem was solved then, but now it
reappears for me in RH8.0.
On RH8.0, I am having trouble building an RPM for the Swarm libraries. I
get the same thing whether I use the libtool that is distributed with
RH8.0 or I use the libtool-1.4c edition that I took from their CVS last
year and built into rpms mentioned above. I can build/install Swarm just
fine with the regular old configure/make/make install, but if I try to
build the rpm I get a libtool failure because it can't find libraries
that are installed in the buildroot. After the SPEC file dictates this
make prefix=$RPM_BUILD_ROOT%{prefix} install
That causes the install into /tmp/swarm-root/usr and all the "first
wave" of libraries (libspace, libactivity, etc) get dumped in there, but
libtool tries to relink, it fails. Observe please that it builds
libspace, copies it into the build root, and then can't find -lspace.
/bin/sh ../../libtool --mode=install /usr/bin/install -c libspace.la
/tmp/swarm-root/usr/lib/swarm/libspace.la
/usr/bin/install -c .libs/libspace.so.2.0.1
/tmp/swarm-root/usr/lib/swarm/libspace.so.2.0.1
(cd /tmp/swarm-root/usr/lib/swarm && rm -f libspace.so.2 && ln -s
libspace.so.2.0.1 libspace.so.2)
(cd /tmp/swarm-root/usr/lib/swarm && rm -f libspace.so && ln -s
libspace.so.2.0.1 libspace.so)
/usr/bin/install -c .libs/libspace.lai
/tmp/swarm-root/usr/lib/swarm/libspace.la
/usr/bin/install -c .libs/libspace.a
/tmp/swarm-root/usr/lib/swarm/libspace.a
ranlib /tmp/swarm-root/usr/lib/swarm/libspace.a
chmod 644 /tmp/swarm-root/usr/lib/swarm/libspace.a
libtool: install: warning: remember to run `libtool --finish /usr/lib/swarm'
/bin/sh
/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/mkinstalldirs
/tmp/swarm-root/usr/include/swarm
/usr/bin/install -c -m 644
/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/src/space/space.h
/tmp/swarm-root/usr/include/swarm/space.h
/bin/sh
/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/mkinstalldirs
/tmp/swarm-root/usr/include/swarm/space
mkdir /tmp/swarm-root/usr/include/swarm/space
/usr/bin/install -c -m 644
/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/src/space/Ca2d.h
/tmp/swarm-root/usr/include/swarm/space/Ca2d.h
/usr/bin/install -c -m 644
/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/src/space/ConwayLife2d.h
/tmp/swarm-root/usr/include/swarm/space/ConwayLife2d.h
/usr/bin/install -c -m 644
/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/src/space/DblBuffer2d.h
/tmp/swarm-root/usr/include/swarm/space/DblBuffer2d.h
/usr/bin/install -c -m 644
/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/src/space/Diffuse2d.h
/tmp/swarm-root/usr/include/swarm/space/Diffuse2d.h
/usr/bin/install -c -m 644
/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/src/space/Discrete2d.h
/tmp/swarm-root/usr/include/swarm/space/Discrete2d.h
/usr/bin/install -c -m 644
/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/src/space/Grid2d.h
/tmp/swarm-root/usr/include/swarm/space/Grid2d.h
/usr/bin/install -c -m 644
/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/src/space/Int2dFiler.h
/tmp/swarm-root/usr/include/swarm/space/Int2dFiler.h
/usr/bin/install -c -m 644
/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/src/space/Object2dDisplay.h
/tmp/swarm-root/usr/include/swarm/space/Object2dDisplay.h
/usr/bin/install -c -m 644
/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/src/space/Value2dDisplay.h
/tmp/swarm-root/usr/include/swarm/space/Value2dDisplay.h
make[3]: Leaving directory
`/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/=with-hdf/src/space'
make[2]: Leaving directory
`/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/=with-hdf/src/space'
make[2]: Entering directory
`/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/=with-hdf/src'
make[3]: Entering directory
`/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/=with-hd
Re: [Mingw-msys] Proposed libtool patch for MinGW
On Tue, 15 Oct 2002, Earnie Boyd wrote:
> Is your patch against CVS head? Or the release 1.4.2?
CVS head.
Bob
>
> Earnie.
>
> Bob Friesenhahn wrote:
> > The attached patch to FSF CVS libtool is intended to make libtool
> > (mostly) behave as it does for Cygwin when executed with MinGW. It
> > consists of contributions from Elizabeth Barham, and my own efforts.
> >
> > The DLLs are installed to $(libdir)/../bin as they currently are under
> > Cygwin. Any change to this scheme should be common to both Cygwin &
> > MinGW unless there is a reason for behaving differently.
> >
> > This patch allows a shared library build of ImageMagick (using both C
> > & C++) to successfully build and install under MinGW using the MSYS
> > shell environment. I have not tried to build libtool modules with it
> > yet (should be interesting).
> >
> > I am posting this patch with the expectation that concerned parties
> > will inspect it, test it, and send any fixes so that it can be
> > incorporated in libtool 1.5.
> >
> > Bob
> > ==
> > Bob Friesenhahn
> > [EMAIL PROTECTED]
> > http://www.simplesystems.org/users/bfriesen
> >
> >
> >
> >
> > Index: libtool.m4
> > ===
> > RCS file: /cvsroot/libtool/libtool/libtool.m4,v
> > retrieving revision 1.266
> > diff -u -r1.266 libtool.m4
> > --- libtool.m4 11 Oct 2002 15:52:08 - 1.266
> > +++ libtool.m4 15 Oct 2002 18:47:45 -
> > @@ -620,7 +620,14 @@
> > lt_cv_sys_max_cmd_len=-1;
> > ;;
> >
> > - *)
> > +
> > + mingw*)
> > +# On msys 1.0 and win98, the maximum length was something like
> > +# 200,000 and took around 45 minutes to get there... ouch!
> > +lt_cv_sys_max_cmd_len=8192;
> > +;;
> > +
> > + *)
> > # If test is not a shell built-in, we'll probably end up computing a
> > # maximum length that is only half of the actual maximum length, but
> > # we can't tell.
> > @@ -1131,7 +1138,8 @@
> > shlibpath_overrides_runpath=yes
> > ;;
> >yes,mingw*)
> > -library_names_spec='${libname}`echo ${release} | sed -e
>'s/[[.]]/-/g'`${versuffix}.dll'
> > +library_names_spec='$libname.dll.a'
> > +soname_spec='${libname}`echo ${release} | sed -e
>'s/[[.]]/-/g'`${versuffix}.dll'
> > sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:" | sed
>-e "s/^libraries://" -e "s,=/,/,g"`
> > if echo "$sys_lib_search_path_spec" | [egrep ';[c-zC-Z]:/' >/dev/null]; then
> ># It is most probably a Windows format PATH printed by
> > @@ -1144,6 +1152,14 @@
> > else
> >sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | sed -e
>"s/$PATH_SEPARATOR/ /g"`
> > fi
> > +postinstall_cmds='dlpath=`sh 2>&1 -c '\''. $dir/${file}i;echo \$dlname'\''`~
> > + dldir=$destdir/`dirname \$dlpath`~
> > + test -d \$dldir || mkdir -p \$dldir~
> > + $install_prog .libs/$dlname \$dldir/$dlname'
> > +postuninstall_cmds='dldll=`sh 2>&1 -c '\''. $file; echo \$dlname'\''`~
> > + dlpath=$dir/\$dldll~
> > + $rm \$dlpath'
> > +shlibpath_overrides_runpath=yes
> > ;;
> >yes,pw32*)
> > library_names_spec='`echo ${libname} | sed -e 's/^lib/pw/'``echo ${release} |
>sed -e 's/[.]/-/g'`${versuffix}.dll'
> > @@ -2624,12 +2640,25 @@
> > else
> >_LT_AC_TAGVAR(ld_shlibs, $1)=no
> > fi
> > -;;
> > + ;;
> >
> > - mingw* | pw32*)
> > -# FIXME: insert proper C++ library support
> > - _LT_AC_TAGVAR(ld_shlibs, $1)=no
> > -;;
> > + mingw* )
> > +_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
> > +_LT_AC_TAGVAR(always_export_symbols, $1)=no
> > +
> > +if $LD --help 2>&1 | egrep 'auto-import' > /dev/null; then
> > + _LT_AC_TAGVAR(archive_cmds, $1)='$CC '$lt_cv_cc_dll_switch' $libobjs
>$deplibs $compiler_flags -o $output_objdir/$soname ${wl}--out-implib,${lib}'
> > + _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC '$lt_cv_cc_dll_switch' $libobjs
>$deplibs $compiler_flags -o $output_objdir/$soname ${wl}-retain-symbols-file
>$wl$export_symbols ${wl}--out-implib,${lib}'
> > +else
> > + _LT_AC_TAGVAR(ld_shlibs, $1)=no
> > +fi
> > + ;;
> > +
> > +
> > + pw32* )
> > + # FIXME: insert proper C++ library support
> > +_LT_AC_TAGVAR(ld_shlibs, $1)=no
> > + ;;
> >
> >dgux*)
> > case $cc_basename in
> > @@ -4517,7 +4546,7 @@
> >_LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM -BCpg $libobjs $convenience |
>awk '\''{ if (((\[$]2 == "T") || (\[$]2 == "D") || (\[$]2 == "B")) &&
>([substr](\[$]3,1,1) != ".")) { print \[$]3 } }'\'' | sort -u > $export_symbols'
> > fi
> > ;;
> > - mingw* | pw32*)
> > + pw32*)
> > _LT_AC_TAGVAR(export_symbols_cmds, $1)="$ltdll_cmds"
> >;;
> >*)
> > @@ -4621,7 +4650,7 @@
> >fi
> >;;
> >
> > -cygwin*)
> > +cygwin* |
Re: [Mingw-msys] Re: MinGW libtool DLL failure
On Tue, Oct 15, 2002 at 10:43:08AM -0500, Bob Friesenhahn wrote: > On Tue, 15 Oct 2002, Max Bowsher wrote: > > > > >> The idea of supporting a --bindir option is tempting, but then > > >> 'libtool --mode=install' stops looking like a simple install program, > > >> and in fact, the --bindir option would need to be passed for several > > >> different phases of libtool operation since it would influence the > > >> content of the library.la file. Since Windows may be the only OS > > >> benefiting from this, we could have a case of the tail wagging the > > >> dog. > > > > So we conditionalize all this so it only activates on Windows. > > There is a fundamental flaw with this logic. Sorry to dissapoint you, > but most open source software using libtool does not originate from > the Windows environment. :-) > > If you rely on a feature which only takes effect under Windows, then > packages will neglect to enable or test that feature, resulting in > packages which do not build properly (or misbehave) under Windows. Doesn't this conflict with the libtool option -no-undefined: - Macro: AC_LIBTOOL_WIN32_DLL This macro should be used if the package has been ported to build clean dlls on win32 platforms. Usually this means that any library data items are exported with `__declspec(dllexport)' and imported with `__declspec(dllimport)'. If this macro is not used, libtool will assume that the package libraries are not dll clean and will build only static libraries on win32 hosts. This macro must be called *before* `AC_PROG_LIBTOOL', and provision must be made to pass `-no-undefined' to `libtool' in link mode from the package `Makefile'. Naturally, if you pass `-no-undefined', you must ensure that all the library symbols *really are* defined at link time! It seems that CYGWIN needs -no-undefined but this might be problematic on other unices. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re:
Title: Untitled Document Problemas de seguridad de Outlook Express: sale otro parche. La vulnerabilidad encontrada es bastante seria y permite a los hackers o bien bloquear el funcionamiento del programa, o lo que es peor, ejecutar un código cualquiera en la máquina.. Casio CW-100: nueva impresora térmica para discos CD/DVD. ¿Será la frecuencia funcional recomendada del NV30 igual a 400 MHz? Sistema acústico SP 53 de 5.1 canales de ABIT: especificaciones y precios. Los paleontólogos por primera vez obtienen una momia de un dinosaurio en condiciones óptimas. El cadaver momificado del dinosaurio, que estuvo enterrado debajo de la tierra durante 77 millones de años, fue encontrado al norte del estado de Montana, nos cuenta Nationalgeografic.com. El hallazgo lo llamaron Leonardo en honor a un graffiti pintado cerca (Leonard Webb and Geneva Jordan, 1917). Leonardo es un dinosaurio ... A los pobladores de Alaska les aterroriza un pterodáctilo gigante. El tratamiento genético contra la calvicie hará que el pelo brille con colores amarillo, verde, azul o rojo. La estación espacial sigue en obras. Mecano Lego: estructuras en cuatro dimensiones. Hay gente que afirma ser constructores profesionales de mecano. Estas afirmaciones afectan sobre todo los famoso mecanos Lego. Asimismo, un hombre llamado Andrew Lipson afirma ser el professional nerd. De su arte vamos a hablar hoy... Clonacion humana es imposible, pero inevitable. Hoy en dia, cuando ya se sabe que ir y hacer un ejercito de clones - casihumanos idénticos - es imposible, la situación de la clonación humana es precaria. No podemos esperar nada sensacional, pero... www.xtio.com
Re: [ 101415 ] libtool + C++ + gcc on solaris
This problem does not exist in the CVS version of libtool, which uses the C++ compiler to link C++ objects. The fix will be in libtool 1.5. Bob On Fri, 18 Oct 2002 [EMAIL PROTECTED] wrote: > > > Support Request #101415, was updated on 2002-Oct-18 09:55 > You can respond by visiting: > http://savannah.gnu.org/support/?func=detailsupport&support_id=101415&group_id=25 > > Category: None > Status: Open > Priority: 5 > Summary: libtool + C++ + gcc on solaris > > By: David.Decotigny > Date: 2002-Oct-18 09:55 > Logged In: NO > Browser: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1) Gecko/20020827 > > We have gcc-3.2 here compiled using: > --enable-shared --with-as=/usr/ccs/bin/as > --with-ld=/usr/ccs/bin/ld > > When configure runs libtool, it discovers that gcc does > not use a GNU ld, which is just the case. So, when > creating a shared library, it will be the case that > libtool will "manually" invoke the ld (/usr/ccs/bin/ld > here). Why not... BUT... > > The library works fine as long as there are no C++ > global objects that are expected to be constructed > before main() (ie global objects declared in a c++ > source as "MyClass object(init_parameters)). If there > are such objects, the behavior any program dynamically > linked against the library is to simply ignore them, or > to crash in the middle of the objects instanciations... > > I noticed that building the library manually with > "gcc-3.2 -shared" instead of the "ld" command line set > by libtool, will result in a correct behavior: > everything will be correctly initialized before main(). > If I add the crtbegin/crti/crtend objects in the > library, it actually seems to work fine too. > > So the question: why try to guess a (apparently broken) > ld command line, since gcc -shared seems to do the job > right? > > -- > You can respond by visiting: > http://savannah.gnu.org/support/?func=detailsupport&support_id=101415&group_id=25 > > > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/libtool > == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
On Fri, 18 Oct 2002, Albert Chin wrote: > On Tue, Oct 15, 2002 at 10:43:08AM -0500, Bob Friesenhahn wrote: > > On Tue, 15 Oct 2002, Max Bowsher wrote: > > > > > > >> The idea of supporting a --bindir option is tempting, but then > > > >> 'libtool --mode=install' stops looking like a simple install program, > > > >> and in fact, the --bindir option would need to be passed for several > > > >> different phases of libtool operation since it would influence the > > > >> content of the library.la file. Since Windows may be the only OS > > > >> benefiting from this, we could have a case of the tail wagging the > > > >> dog. > > > > > > So we conditionalize all this so it only activates on Windows. > > > > There is a fundamental flaw with this logic. Sorry to dissapoint you, > > but most open source software using libtool does not originate from > > the Windows environment. :-) > > > > If you rely on a feature which only takes effect under Windows, then > > packages will neglect to enable or test that feature, resulting in > > packages which do not build properly (or misbehave) under Windows. > > Doesn't this conflict with the libtool option -no-undefined: > - Macro: AC_LIBTOOL_WIN32_DLL > This macro should be used if the package has been ported to build > clean dlls on win32 platforms. Usually this means that any Due to `auto-import' enhancements in the version of binutils used by Cygwin and MinGW, I believe that using this macro is no longer necessary. Packages which have been enhanced (or compromised, depending on point of view) by being decorated with dllexport/dllimport annotations may still benefit from use of the macro. Unix-derived packages which do not use AC_LIBTOOL_WIN32_DLL and do not incorporate dllexport/dllimport annotations are capable of building DLLs by incorporating recent libtool. > It seems that CYGWIN needs -no-undefined but this might be problematic > on other unices. It is true that Cygwin/MinGW need -no-undefined in order to build DLLs. I have not encountered a problem with specifying -no-undefined under various unixes. Indeed, I believe that this issue isn't Windows specific because IBM's AIX also requires -no-undefined. In order to ensure that the maximum number of packages will compile under Windows, the auto* tools should automatically incorporate any tests/features required for packages to build under Windows without their authors taking specific action to make this possible. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Add hppa*64* support to libtool
On Fri, 18 Oct 2002 13:34:06 -0500 (CDT)
Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
Bob,
I sent a patch to libtool-patch about a week ago. The patch
was against libtool-1.4e. I will get the latest libtool.m4
from CVSweb and redo the patch. It is fairly extensive
reworking of the hpux code. The email below wasn't intended
to be applied directly, instead it was for people who are
interested to check the changes without diff code getting
in the way. It does somewhat more than just add PA64 support,
as it moves the hpux9 code into its own case in the C++
and standard shared library support macros and I need to know
how this will be received. It isn't strictly necessary but it
does make modified the hpux10/hpux11 (really just hpux11)
configuration that much easier. If there is a particular
maintainer of the hpux code, can they get in touch with me ASAP.
Many thanks
Ross
> What version of libtool are these changes against? Please submit a
> formal patch (with ChangeLog entry) against the head of FSF libtool
> CVS.
>
> Thanks,
>
> Bob
>
> On Thu, 17 Oct 2002 [EMAIL PROTECTED] wrote:
>
> >
> > Dave,
> >
> > I have removed the GNU ld cases from the C and C++ shared library building
> > code. The +std isn't really necessary. The concern was a user would pass
> > +compat in CC_OPTS or CC='cc +compat' and cause libtool to fall into a
> > heap.
> >
> > Below are the various changes (not the whole file because the libtool
> > mailing
> > list will bounce it). By the way, is the IA64 case IA64 or IA64*?
> >
> > I haven't removed the -fPIC or +Z code. I'm not sure that it is very
> > important.
> >
> > Many thanks
> >
> > Ross
> >
> > hpux9* | hpux10* | hpux11*)
> > # Give a soname corresponding to the major version so that dld.sl refuses
> > to
> > # link against other versions.
> > version_type=sunos
> > need_lib_prefix=no
> > need_version=no
> > case "$host_cpu" in
> > ia64*)
> > hardcode_into_libs=yes
> > dynamic_linker="$host_os dld.so"
> > shlibpath_var=LD_LIBRARY_PATH
> > shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
> > library_names_spec='${libname}${release}.so$versuffix ${libname}
> > ${release}.so$major $libname.so'
> > soname_spec='${libname}${release}.so$major'
> > if test "X$HPUX_IA64_MODE" = X32; then
> > sys_lib_search_path_spec="/usr/lib/hpux32 /usr/local/lib/hpux32
> > /usr/local/lib"
> > else
> > sys_lib_search_path_spec="/usr/lib/hpux64 /usr/local/lib/hpux64"
> > fi
> > sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
> > ;;
> > hppa*64*)
> > hardcode_into_libs=yes
> > dynamic_linker="$host_os dld.sl"
> > shlibpath_var=LD_LIBRARY_PATH # How should we handle SHLIB_PATH
> > shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
> > library_names_spec='${libname}${release}.sl$versuffix ${libname}
> > ${release}.sl$major $libname.sl'
> > soname_spec='${libname}${release}.sl$major'
> > sys_lib_search_path_spec="/usr/lib/pa20_64 /usr/ccs/lib/pa20_64"
> > sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
> > ;;
> > *)
> > dynamic_linker="$host_os dld.sl"
> > shlibpath_var=SHLIB_PATH
> > shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
> > library_names_spec='${libname}${release}.sl$versuffix ${libname}
> > ${release}.sl$major $libname.sl'
> > soname_spec='${libname}${release}.sl$major'
> > sys_lib_search_path_spec="/lib /usr/lib /usr/ccs/lib"
> > sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
> > esac
> > # HP-UX runs *really* slowly unless shared libraries are mode 555.
> > postinstall_cmds='chmod 555 $lib'
> > ;;
> >
> > ...
> >
> > hpux10.20* | hpux11*)
> > lt_cv_file_magic_cmd=/usr/bin/file
> > case "$host_cpu" in
> > ia64*)
> > lt_cv_deplibs_check_method='file_magic (s[[0-9]][[0-9]][[0-9]]
> > |ELF-[[0-9]][[0-9]]) shared object file - IA64'
> > lt_cv_file_magic_test_file=/usr/lib/hpux32/libc.so
> > ;;
> > hppa*64*)
> > lt_cv_deplibs_check_method='file_magic ELF-64 shared object file -
> > PA-RISC [[0-9]].[[0-9]]'
> > lt_cv_file_magic_test_file=/usr/lib/pa20_64/libc.sl
> > ;;
> > *)
> > lt_cv_deplibs_check_method='file_magic (s[[0-9]][[0-9]][[0-9]]|PA-RISC
> > [[0-9]].[[0-9]]) shared library'
> > lt_cv_file_magic_test_file=/usr/lib/libc.sl
> > ;;
> > esac
> > ;;
> >
> > ...
> >
> >
> > hpux10*|hpux11*)
> > if test "$with_gnu_ld" = no; then
> > case "$host_cpu" in
> > ia64*|hppa*64*)
> > _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
> > _LT_AC_TAGVAR(hardcode_direct, $1)=no
> > ;;
> > *)
> > _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
> > _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
> > _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
> > _LT_AC_TAGVAR(hardcode_direct, $1)=yes
> > ;;
> > esac
> >
Please re-submit Cygwin patch
Charles, Please re-send your Cygwin patch. I tried retrieving the patch you sent from http://mail.gnu.org/pipermail/libtool-patches/2002-October/002100.html since I never recieved it from the list, but patch does a terrible job with it, applying the patches to the wrong places in the file (offsets of +-56!). This may be because the mail archive is in HTML format, and saving to text makes it subject to the formatting whims of my browser. I also saved directly to HTML but that actually did worse. Thanks, Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Please re-submit Cygwin patch
> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes: Bob> This may be because the mail archive is in HTML format, and Bob> saving to text makes it subject to the formatting whims of my Bob> browser. I also saved directly to HTML but that actually did Bob> worse. FWIW: I find the appended script useful for applying patches from web archives. `fixpatch' and `clcleanup' are optional; you can find them in Alexandre Oliva's cvsutils. Tom #! /bin/sh # Usage: wpatch URL # Download URL and prep for patching. url=$1 wget -O- $url | recode HTML..UTF-8 | fixpatch | clcleanup ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
