Re: autoreconf misses ltmain.sh

[Akim Demaille]

| Am Mon, 2002-09-23 um 10.49 schrieb Alexandre Duret-Lutz:
| > >>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
| > 
| > [...]
| > 
| >  Ralf> http://mail.gnu.org/pipermail/libtool-patches/2002-January/001659.html
| > 
| >  Ralf> .. which seems to indicate that libtool is the culprit.
| >  Ralf> => There doesn't exist any officially released version of libtool that
| >  Ralf> is usable with autoconf-2.54 and automake-1.7
| > 
| > Not exactly: there is no release of Libtool that honors
| > AC_CONFIG_AUX_DIR in configure.*ac*.
| > 
| >  Ralf> .. still nobody wanting to care to fix it?
| > 
| > AFAICT it's fixed in CVS Libtool.
| 
| We are talking about released SW rsp. to be released SW here.
| 
| The current situation is: libtool and autoreconf do not interact
| together, rendering autoreconf entirely useless and unreliable in total
| in many situations, no matter if libtool is the culprit or not.
| 
| Pointing users to cvs versions is acceptable as long a tool is in
| development, however once a tool is release, this situation changes.
| Read: Users will yell at autoconf, because _it_ can't deal with released
| versions of libtool.
| 
| In my opinion it is prohibitive and stupid not to have a libtool release
| that can properly interact with autoconf.

This is my opinion too, and I have regularly sent messages to the
Libtool lists, but without affect.  They are still in CC of these
messages, but without any answer.

So as was kindly suggested by TED, we should have autoreconf work
around Libtool problems.  I have not read all the details yet, but
does anybody know what we must do to cope with Libtool 1.4.2?  Or,
does anybody know when another Libtool will be released?


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: autoreconf misses ltmain.sh

[Akim Demaille]

> "Roger" == Roger Leigh <[EMAIL PROTECTED]> writes:

Ralf> .. still nobody wanting to care to fix it?
>> AFAICT it's fixed in CVS Libtool.

Roger> And in Debian.

Am I crazy suggesting that Debian Libtool be the next Libtool release?


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Automake 1.6d available (beta for Automake 1.7)

[Akim Demaille]

| Alexandre Duret-Lutz wrote:
| >  Bruce> My preference would be this:
| > 
| > Could you send this to the list?
| 
| Alright:
| 
| I would really like to see the auto* tools packages (autoconf,
| automake and libtool) each adopt several of their worst
| clients' packages for regression testing.

It's already the case, as you just proved.



I appreciate very much your suggestions, but I have another: run the
betas.  Once there will be enough people running the betas, there will
probably be less bugs released.  As of today, I run CVS Autoconf
etc. on a large set of packages, including the very demanding
Coreutils.  Plus I send announcements for betas.  After this, I feel
in peace with myself when I release.


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: autoreconf misses ltmain.sh

[Paul Eggert]

> From: Akim Demaille <[EMAIL PROTECTED]>
> Date: 24 Sep 2002 13:33:43 +0200
> 
> So as was kindly suggested by TED, we should have autoreconf work
> around Libtool problems.

I missed that suggestion somewhere in my mailbox (currently with 2035
messages to read, sigh); if you think it preferable to the patch
below, can you please send a URL?


> I have not read all the details yet, but does anybody know what we
> must do to cope with Libtool 1.4.2?

How about this patch to Autoconf?  It should let us limp along until a
new libtool version is published.  (In this patch I resisted the
temptation to append "Libtool?  Run away!  Run away!")

--- old/BUGS2002-03-26 08:14:37.0 -0800
+++ new/BUGS2002-09-24 06:35:04.496461535 -0700
@@ -38,3 +38,12 @@
 /*--.
 | Sane for full scale use.  |
 `--*/
+
+* Interoperability bugs
+
+** AC_CONFIG_AUX_DIR and libtool 1.4.2.
+
+Autoconf-generated scripts that use AC_CONFIG_AUX_DIR do not work with
+libtool 1.4.2.  Robert Boehne and Michael Matz have published a patch
+for libtool in:
+.


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?

[Earnie Boyd]

Elizabeth Barham wrote:
> 
> Hi,
> 
> A while back, Bob mentioned running into some trouble linking a dll
> with the stub lib*.a libraries:
> 
> 
> 
> and has contributed some patches to libtool (whether in regards to
> this I do not know).
> 
> Anyway, I, too, recently had a similar error as what Bob mentioned in
> the previous email cited above.
> 
> So, I am curious as to whether or not the kink has been ironed out.
> 

Not, totally, but it's being worked upon.  I've joined the libtool list
as well in order to help with resolving the issues with mingw32
host/build/target issues.  Hopefully, others that have been actively
working with mingw32 libtool issues can speak to this issue.

What is your current problem in detail?  I.E.: What is failing?

Earnie.


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?

[Bob Friesenhahn]

On Tue, 24 Sep 2002, Earnie Boyd wrote:

> Elizabeth Barham wrote:
> >
> > A while back, Bob mentioned running into some trouble linking a dll
> > with the stub lib*.a libraries:
> >
> > 
> >
> > and has contributed some patches to libtool (whether in regards to
> > this I do not know).
> >
> > Anyway, I, too, recently had a similar error as what Bob mentioned in
> > the previous email cited above.
> >
> > So, I am curious as to whether or not the kink has been ironed out.

This update to CVS libtool resolves most of these problems:

2002-06-26  Bob Friesenhahn  <[EMAIL PROTECTED]>

* libtool.m4 (AC_LIBTOOL_SYS_DYNAMIC_LINKER) [mingw]: Remove
extraneous '=' character which appears in gcc 3.1
-print-search-dirs output.
Handle both upper and lower case drive letters when testing for
Windows vs POSIX style path output from -print-search-dirs
output.

The problem is that some directories searched by the compiler were
being ignored by libtool due to the two listed problems (particularly
the second one, which caused the MinGW libs to be ignored).

Using CVS libtool I am able to build static libraries against a set of
DLLs, but there are failures if --enable-shared is added to the
configure arguments.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

cygwin static archives piecewise

[David Thompson]

I have a project that builds a large library. So big that it needs to 
do piecewise archiving on cygwin. Within cygwin, the command that is 
getting issued for building the static lib is:

LIB /OUT:library.lib $object_files

All is fine and dandy until it issues the next piece to be added and it issues:

LIB /OUT:library.lib $object_files2

The problem is, LIB /OUT is telling lib to replace the previous 
archived objects. Instead the two pieces should be:

LIB /OUT:library.lib $object_files
LIB library.lib $object_files2

This would append the $object_files2 to the archive. I looked at the 
generated libtool and the biggest problem is that /OUT:library.lib is 
part of the old_archive_cmds variable. So this needs to be broke up 
differently. Has this work already been fixed in CVS? Should I work 
on it?

David
-- 
.
David L. Thompson  The University of Montana
mailto:[EMAIL PROTECTED] Computer Science Department
http://www.cs.umt.edu/u/dthompsn   Missoula, MT  59812
Work Phone : (406)257-8530


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?

[Elizabeth Barham]

Earnie Boyd <[EMAIL PROTECTED]> writes:

> Not, totally, but it's being worked upon.  I've joined the libtool list
> as well in order to help with resolving the issues with mingw32
> host/build/target issues.  Hopefully, others that have been actively
> working with mingw32 libtool issues can speak to this issue.
> 
> What is your current problem in detail?  I.E.: What is failing?

I'd like to automate libxml2's build for a mingw system but it's
failing when it tries to build the actual library:

/bin/sh ./libtool --mode=link i586-mingw32msvc-gcc  -g -O2 -Wall  -o libxml2.la -rpath 
/usr/local/lib -version-info 6:24:4 -no-undefined SAX.lo entities.lo encoding.lo 
error.lo parserInternals.lo parser.lo tree.lo hash.lo list.lo xmlIO.lo xmlmemory.lo 
uri.lo valid.lo xlink.lo HTMLparser.lo HTMLtree.lo debugXML.lo xpath.lo xpointer.lo 
xinclude.lo nanohttp.lo nanoftp.lo DOCBparser.lo catalog.lo globals.lo threads.lo 
c14n.lo xmlregexp.lo xmlschemas.lo xmlschemastypes.lo xmlunicode.lo  -lm -lwsock32 
rm -fr .libs/libxml2.la .libs/libxml2.* .libs/libxml2.*

*** Warning: linker path does not have real file for library -lm.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libm but no candidates were found. (...for file magic test)

*** Warning: linker path does not have real file for library -lwsock32.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libwsock32 but no candidates were found. (...for file magic test)
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
i586-mingw32msvc-ar cru .libs/libxml2.a  SAX.o entities.o encoding.o error.o 
parserInternals.o parser.o tree.o hash.o list.o xmlIO.o xmlmemory.o uri.o valid.o 
xlink.o HTMLparser.o HTMLtree.o debugXML.o xpath.o xpointer.o xinclude.o nanohttp.o 
nanoftp.o DOCBparser.o catalog.o globals.o threads.o c14n.o xmlregexp.o xmlschemas.o 
xmlschemastypes.o xmlunicode.o 
i586-mingw32msvc-ranlib .libs/libxml2.a
creating libxml2.la

(etc... the static library)

It went further without the -lm and -lwsock32 but there were many
unresolved symbols.

I was wondering if libwsock32 was a normal archive but the output of
strings suggests it is an import library:

(...)
_GetAddressByNameA@40
__imp__GetAddressByNameA@40
_GetAcceptExSockaddrs@32
__imp__GetAcceptExSockaddrs@32
_EnumProtocolsW@12
__imp__EnumProtocolsW@12
_EnumProtocolsA@12
__imp__EnumProtocolsA@12
_AcceptEx@32
__imp__AcceptEx@32
dt.o/   1007767756  0 0 100664  539   `
.text
`.data
.bss
.idata$4
.idata$5
.idata$7
WSOCK32.DLL
.text
.data
.bss
.idata$4
.idata$5
.idata$7
__libwsock32_a_iname
dh.o/   1007767756  0 0 100664  651   `
(...)

lizzy@shelby:/usr/i586-mingw32msvc/lib$ file libwsock32.a 
libwsock32.a: current ar archive

So I was just wondering about it if the new patches figure out that
the stub libraries are not really static.

Elizabeth


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?

[Earnie Boyd]

Elizabeth Barham wrote:
> 
> Earnie Boyd <[EMAIL PROTECTED]> writes:
> 
> > Not, totally, but it's being worked upon.  I've joined the libtool list
> > as well in order to help with resolving the issues with mingw32
> > host/build/target issues.  Hopefully, others that have been actively
> > working with mingw32 libtool issues can speak to this issue.
> >
> > What is your current problem in detail?  I.E.: What is failing?
> 
> I'd like to automate libxml2's build for a mingw system but it's
> failing when it tries to build the actual library:
> 
> /bin/sh ./libtool --mode=link i586-mingw32msvc-gcc  -g -O2 -Wall  -o libxml2.la 
>-rpath /usr/local/lib -version-info 6:24:4 -no-undefined SAX.lo entities.lo 
>encoding.lo error.lo parserInternals.lo parser.lo tree.lo hash.lo list.lo xmlIO.lo 
>xmlmemory.lo uri.lo valid.lo xlink.lo HTMLparser.lo HTMLtree.lo debugXML.lo xpath.lo 
>xpointer.lo xinclude.lo nanohttp.lo nanoftp.lo DOCBparser.lo catalog.lo globals.lo 
>threads.lo c14n.lo xmlregexp.lo xmlschemas.lo xmlschemastypes.lo xmlunicode.lo  -lm 
>-lwsock32

If course -lm isn't needed for mingw32, there are 3rd party libraries
that can be built to provide one though.  The easy work-around is to
remove the -lm from the list of libraries in the Makefile.  The
permanent fix would be a rework of the autoconfistification for libxml2
to not include the -lm for target *mingw32*.

> rm -fr .libs/libxml2.la .libs/libxml2.* .libs/libxml2.*
> 
> *** Warning: linker path does not have real file for library -lm.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libm but no candidates were found. (...for file magic test)
> 
> *** Warning: linker path does not have real file for library -lwsock32.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libwsock32 but no candidates were found. (...for file magic test)
> *** The inter-library dependencies that have been dropped here will be
> *** automatically added whenever a program is linked with this library
> *** or is declared to -dlopen it.
> 
> *** Since this library must not contain undefined symbols,
> *** because either the platform does not support them or
> *** it was explicitly requested with -no-undefined,
> *** libtool will only create a static version of it.
> i586-mingw32msvc-ar cru .libs/libxml2.a  SAX.o entities.o encoding.o error.o 
>parserInternals.o parser.o tree.o hash.o list.o xmlIO.o xmlmemory.o uri.o valid.o 
>xlink.o HTMLparser.o HTMLtree.o debugXML.o xpath.o xpointer.o xinclude.o nanohttp.o 
>nanoftp.o DOCBparser.o catalog.o globals.o threads.o c14n.o xmlregexp.o xmlschemas.o 
>xmlschemastypes.o xmlunicode.o
> i586-mingw32msvc-ranlib .libs/libxml2.a
> creating libxml2.la
> 
> (etc... the static library)
> 
> It went further without the -lm and -lwsock32 but there were many
> unresolved symbols.
> 

It would need -lwsock32 or -lws2_32 to resolve the unresolved symbols. 
Static libraries can use shared library symbols.

> I was wondering if libwsock32 was a normal archive but the output of
> strings suggests it is an import library:
> 
> (...)
> _GetAddressByNameA@40
> __imp__GetAddressByNameA@40
> _GetAcceptExSockaddrs@32
> __imp__GetAcceptExSockaddrs@32
> _EnumProtocolsW@12
> __imp__EnumProtocolsW@12
> _EnumProtocolsA@12
> __imp__EnumProtocolsA@12
> _AcceptEx@32
> __imp__AcceptEx@32
> dt.o/   1007767756  0 0 100664  539   `
> .text
> `.data
> .bss
> .idata$4
> .idata$5
> .idata$7
> WSOCK32.DLL
> .text
> .data
> .bss
> .idata$4
> .idata$5
> .idata$7
> __libwsock32_a_iname
> dh.o/   1007767756  0 0 100664  651   `
> (...)
> 
> lizzy@shelby:/usr/i586-mingw32msvc/lib$ file libwsock32.a
> libwsock32.a: current ar archive
> 
> So I was just wondering about it if the new patches figure out that
> the stub libraries are not really static.
> 

I don't understand the point here.

Earnie.


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?

[Guido Draheim]

Elizabeth Barham wrote:
> Earnie Boyd <[EMAIL PROTECTED]> writes:
> 
> 
>>Not, totally, but it's being worked upon.  I've joined the libtool list
>>as well in order to help with resolving the issues with mingw32
>>host/build/target issues.  Hopefully, others that have been actively
>>working with mingw32 libtool issues can speak to this issue.
>>
>>What is your current problem in detail?  I.E.: What is failing?
> 
> 
> I'd like to automate libxml2's build for a mingw system but it's
> failing when it tries to build the actual library:
> 
> /bin/sh ./libtool --mode=link i586-mingw32msvc-gcc  -g -O2 -Wall  -o libxml2.la 
>-rpath /usr/local/lib -version-info 6:24:4 -no-undefined SAX.lo entities.lo 
>encoding.lo error.lo parserInternals.lo parser.lo tree.lo hash.lo list.lo xmlIO.lo 
>xmlmemory.lo uri.lo valid.lo xlink.lo HTMLparser.lo HTMLtree.lo debugXML.lo xpath.lo 
>xpointer.lo xinclude.lo nanohttp.lo nanoftp.lo DOCBparser.lo catalog.lo globals.lo 
>threads.lo c14n.lo xmlregexp.lo xmlschemas.lo xmlschemastypes.lo xmlunicode.lo  -lm 
>-lwsock32 
> rm -fr .libs/libxml2.la .libs/libxml2.* .libs/libxml2.*
> 
> *** Warning: linker path does not have real file for library -lm.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libm but no candidates were found. (...for file magic test)
> 
> *** Warning: linker path does not have real file for library -lwsock32.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libwsock32 but no candidates were found. (...for file magic test)
> *** The inter-library dependencies that have been dropped here will be
> *** automatically added whenever a program is linked with this library
> *** or is declared to -dlopen it.
> 
> *** Since this library must not contain undefined symbols,
> *** because either the platform does not support them or
> *** it was explicitly requested with -no-undefined,
> *** libtool will only create a static version of it.
> i586-mingw32msvc-ar cru .libs/libxml2.a  SAX.o entities.o encoding.o error.o 
>parserInternals.o parser.o tree.o hash.o list.o xmlIO.o xmlmemory.o uri.o valid.o 
>xlink.o HTMLparser.o HTMLtree.o debugXML.o xpath.o xpointer.o xinclude.o nanohttp.o 
>nanoftp.o DOCBparser.o catalog.o globals.o threads.o c14n.o xmlregexp.o xmlschemas.o 
>xmlschemastypes.o xmlunicode.o 
> i586-mingw32msvc-ranlib .libs/libxml2.a
> creating libxml2.la
> 
> (etc... the static library)
> 
> It went further without the -lm and -lwsock32 but there were many
> unresolved symbols.


'-lm' does not exist on win32, however some autoconf macros add it
to $LIBS automatically. I use an extra configure.ac line to
remove these when the target is win32.

'-wsock32' is a problem - I know that some editions have a dll
being named slightly different (-lws32??). On the other hand,
I might wonder what the real sys_lib_search_path_spec does
look like - can have a look into the (builddir) "libtool"
file? That might give a clue... -- guido
 btw, what libtool version was that again?

> 
> I was wondering if libwsock32 was a normal archive but the output of
> strings suggests it is an import library:
> 
> (...)
> _GetAddressByNameA@40
> __imp__GetAddressByNameA@40
> _GetAcceptExSockaddrs@32
> __imp__GetAcceptExSockaddrs@32
> _EnumProtocolsW@12
> __imp__EnumProtocolsW@12
> _EnumProtocolsA@12
> __imp__EnumProtocolsA@12
> _AcceptEx@32
> __imp__AcceptEx@32
> dt.o/   1007767756  0 0 100664  539   `
> .text
> `.data
> .bss
> .idata$4
> .idata$5
> .idata$7
> WSOCK32.DLL
> .text
> .data
> .bss
> .idata$4
> .idata$5
> .idata$7
> __libwsock32_a_iname
> dh.o/   1007767756  0 0 100664  651   `
> (...)
> 
> lizzy@shelby:/usr/i586-mingw32msvc/lib$ file libwsock32.a 
> libwsock32.a: current ar archive
> 
> So I was just wondering about it if the new patches figure out that
> the stub libraries are not really static.
> 
> Elizabeth
> 
> 
> ___
> Libtool mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/libtool
> 
> 



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?

[Earnie Boyd]

Oscar Fuentes wrote:
> 
> Guido Draheim <[EMAIL PROTECTED]> writes:
> 
> > '-lm' does not exist on win32,
> 
> There is a libm.a on MinGW's lib directory. Seems it is a dummy
> library for those *nix builds that uses -lm.
> 

Oh, yes, I forgot about that.  Should this be removed?

Here's the contents:

$ nm /mingw/lib/libm.a

_libm_dummy.o:
 b .bss
 d .data
 t .text
 b ___mingw_libm_dummy

Earnie.
P.S.: Oscar, please be sure to keep libtool in the distro of the
Reply-To munging.


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Porting libtool to linux-icc (mark II) [PATCH]

[Robert Boehne]

Hello,

I've approved this patch pending copyright assignment.

ChangeLog entry:
2002-09-24  Allan Sandfeld Jensen  <[EMAIL PROTECTED]>

* libtool.m4: Add support for Intel icc compiler for Linux.

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  rboehne AT ricardo-us DOT com




Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.264
diff -u -r1.264 libtool.m4
--- libtool.m4  10 Sep 2002 13:50:06 -  1.264
+++ libtool.m4  24 Sep 2002 23:06:32 -
@@ -2425,7 +2425,7 @@
 _LT_AC_TAGVAR(compiler, $1)=$CC
 cc_basename=`$echo X"$compiler" | $Xsed -e 's%^.*/%%'`
 
-# We don't want -fno-exception wen compiling C++ code, so set the
+# We don't want -fno-exception when compiling C++ code, so set the
 # no_builtin_flag separately
 if test "$GXX" = yes; then
   _LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)=' -fno-builtin'
@@ -2803,6 +2803,19 @@
# dependencies.
output_verbose_link_cmd='templist=`$CC -shared $CFLAGS -v conftest.$objext 
2>&1 | grep "ld"`; templist=`echo $templist | sed "s/\(^.*ld.*\)\( .*ld .*$\)/\1/"`; 
list=""; for z in $templist; do case $z in conftest.$objext) list="$list $z";; 
*.$objext);; *) list="$list $z";;esac; done; echo $list'
;;
+  icpc)
+   # Intel C++
+   with_gnu_ld=yes
+   
+_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+   _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects 
+$libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o $lib'
+   _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared -nostdlib $predep_objects 
+$libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname 
+${wl}-retain-symbols-file $wl$export_symbols -o $lib'
+
+   _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
+   _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
+   
+   _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive$convenience 
+${wl}--no-whole-archive'
+   ;;
 esac
 ;;
   lynxos*)
@@ -4220,6 +4233,12 @@
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
;;
+ icpc)
+   # Intel C++
+   _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption,ld,'
+   _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static'
+   ;; 
  *)
;;
esac
@@ -4416,7 +4435,13 @@
   # PIC (with -KPIC) is the default.
   _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
   ;;
-
+linux*)
+  if test "$CC" = icc; then
+ _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption,ld,'
+ _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static'
+  fi
+  ;;
 newsos6)
   _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
   _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
@@ -5260,6 +5285,9 @@
 # Do we need to explicitly link libc?
 #
 _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=yes
+if test "$enable_shared" = yes && test "$CC" = icc; then
+  _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+fi
 if test "$enable_shared" = yes && test "$GCC" = yes; then
   case $_LT_AC_TAGVAR(archive_cmds, $1) in
   *'~'*)

Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?

[Earnie Boyd]

Hmm..., if libtool.m4 exists in the package, make sure you replace it
with a copy from the CVS and execute aclocal again.

Earnie.

Elizabeth Barham wrote:
> 
> Earnie Boyd <[EMAIL PROTECTED]> writes:
> 
> > Not, totally, but it's being worked upon.  I've joined the libtool list
> > as well in order to help with resolving the issues with mingw32
> > host/build/target issues.  Hopefully, others that have been actively
> > working with mingw32 libtool issues can speak to this issue.
> >
> > What is your current problem in detail?  I.E.: What is failing?
> 
> I'd like to automate libxml2's build for a mingw system but it's
> failing when it tries to build the actual library:
> 
> /bin/sh ./libtool --mode=link i586-mingw32msvc-gcc  -g -O2 -Wall  -o libxml2.la 
>-rpath /usr/local/lib -version-info 6:24:4 -no-undefined SAX.lo entities.lo 
>encoding.lo error.lo parserInternals.lo parser.lo tree.lo hash.lo list.lo xmlIO.lo 
>xmlmemory.lo uri.lo valid.lo xlink.lo HTMLparser.lo HTMLtree.lo debugXML.lo xpath.lo 
>xpointer.lo xinclude.lo nanohttp.lo nanoftp.lo DOCBparser.lo catalog.lo globals.lo 
>threads.lo c14n.lo xmlregexp.lo xmlschemas.lo xmlschemastypes.lo xmlunicode.lo  -lm 
>-lwsock32
> rm -fr .libs/libxml2.la .libs/libxml2.* .libs/libxml2.*
> 
> *** Warning: linker path does not have real file for library -lm.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libm but no candidates were found. (...for file magic test)
> 
> *** Warning: linker path does not have real file for library -lwsock32.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libwsock32 but no candidates were found. (...for file magic test)
> *** The inter-library dependencies that have been dropped here will be
> *** automatically added whenever a program is linked with this library
> *** or is declared to -dlopen it.
> 
> *** Since this library must not contain undefined symbols,
> *** because either the platform does not support them or
> *** it was explicitly requested with -no-undefined,
> *** libtool will only create a static version of it.
> i586-mingw32msvc-ar cru .libs/libxml2.a  SAX.o entities.o encoding.o error.o 
>parserInternals.o parser.o tree.o hash.o list.o xmlIO.o xmlmemory.o uri.o valid.o 
>xlink.o HTMLparser.o HTMLtree.o debugXML.o xpath.o xpointer.o xinclude.o nanohttp.o 
>nanoftp.o DOCBparser.o catalog.o globals.o threads.o c14n.o xmlregexp.o xmlschemas.o 
>xmlschemastypes.o xmlunicode.o
> i586-mingw32msvc-ranlib .libs/libxml2.a
> creating libxml2.la
> 
> (etc... the static library)
> 
> It went further without the -lm and -lwsock32 but there were many
> unresolved symbols.
> 
> I was wondering if libwsock32 was a normal archive but the output of
> strings suggests it is an import library:
> 
> (...)
> _GetAddressByNameA@40
> __imp__GetAddressByNameA@40
> _GetAcceptExSockaddrs@32
> __imp__GetAcceptExSockaddrs@32
> _EnumProtocolsW@12
> __imp__EnumProtocolsW@12
> _EnumProtocolsA@12
> __imp__EnumProtocolsA@12
> _AcceptEx@32
> __imp__AcceptEx@32
> dt.o/   1007767756  0 0 100664  539   `
> .text
> `.data
> .bss
> .idata$4
> .idata$5
> .idata$7
> WSOCK32.DLL
> .text
> .data
> .bss
> .idata$4
> .idata$5
> .idata$7
> __libwsock32_a_iname
> dh.o/   1007767756  0 0 100664  651   `
> (...)
> 
> lizzy@shelby:/usr/i586-mingw32msvc/lib$ file libwsock32.a
> libwsock32.a: current ar archive
> 
> So I was just wondering about it if the new patches figure out that
> the stub libraries are not really static.
> 
> Elizabeth
> 
> ___
> Libtool mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Libtool 1.4.2 and EBCDIC

[Howard Chu]

I don't recall if I submitted this patch already, but this will patch libtool
to properly deal with EndOfLine on EBCDIC systems:
*** ltmain.sh   Fri Jun  7 16:35:33 2002
--- ../ldap/build/ltmain.sh   Thu Sep 19 23:21:52 2002
***
*** 69,76 
--- 74,90 
  # metacharacters that are still active within double-quoted strings.
  Xsed='sed -e 1s/^X//'
  sed_quote_subst='s/\([\\`\\"$]\)/\\\1/g'
+ # test EBCDIC or ASCII
+ case `echo '' | od -x` in
+ *15*) # EBCDIC based system
+   SP2NL='tr \100 \025'
+   NL2SP='tr \025 \100'
+   ;;
+ *) # Assume ASCII based system
SP2NL='tr \040 \012'
NL2SP='tr \015\012 \040\040'
+   ;;
+ esac

  # NLS nuisances.
  # Only set LANG and LC_ALL to C if already set.

  -- Howard Chu
  Chief Architect, Symas Corp.   Director, Highland Sun
  http://www.symas.com   http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool