Re: Win32: Autotools/libtool and MS VC++?

[Morten Eriksen]

Marc van Woerkom <[EMAIL PROTECTED]> writes:

> [...] what happens if one really wants to use the Microsoft C/C++
> compiler?

One solution we've found to work well is to wrap the cl.exe compiler
(and the linker) within a shell script that converts "UNIX-style"
compiler arguments into what MSVC++ expects.

To see our take on how to do that, check out the Coin project at
http://www.coin3d.org>. We've got a MSVC++ script working very
well, and a Borland C++ wrapper script which is not-quite-there.

We even make .dll's with this thing -- but with some hacks. In
general, Autoconf and Automake have all the stuff in place to do a
clean wrapper script for cl.exe, but Libtool doesn't seem to be quite
up to par yet.

I also submitted and got accepted a patch to do dependency tracking
with MSVC++'s cl.exe, so that's already part of the current Automake
CVS.

Regards,
Morten

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

[PATCH] Problem with native IRIX ld

[Morten Eriksen]

Hi,

I've bumped into a rather nasty problem with libtool's "cooperation"
with the native SGI IRIX linker.

Platform:
* SGI IRIX 6.5

* SGI Mipspro CC v7.30

* native ld, $Id$ = IRIX 6.4:1275524910 built 04/21/99
  (couldn't find a way to make it spit out the version or
  release number)

* Libtool v1.3.5


In a nutshell, the problem is that the -set_version option of the
native IRIX linker can't handle optionstrings of more than ~230
characters before it segfaults.

The long version of the problem is that libtool uses IRIX ld's
-set_version to set up the list of interface versions which the
library you're building is meant to be backwards compatible
with. Here's the relevant code from ltmain.sh:

irix)
  major=`expr $current - $age + 1`
  versuffix="$major.$revision"
  verstring="sgi$major.$revision"

  # Add in all the interfaces that we are compatible with.
  loop=$revision
  while test $loop != 0; do
iface=`expr $revision - $loop`
loop=`expr $loop - 1`
verstring="sgi$major.$iface:$verstring"
  done
  ;;


(So if our current major version number is 1 (and age 0), and our
revision is 5, the library will be named libxxx.so.2.5 and the
interface compatibility $verstring will become
"sgi2.4:sgi2.3:sgi2.2:sgi2.1:sgi2.0:sgi2.5".)

The $verstring is then passed to ld's -set_version option in the
generated libtool script, here's the command:

  archive_cmds='$LD -shared $libobjs $deplibs $linkopts -soname $soname `test -n 
"$verstring" && echo -set_version $verstring` -update_registry ${objdir}/so_locations 
-o $lib'

Now, if the $revision number is large, $verstring can quickly get
rather long. IRIX ld will crash if it consists of more than ~230
characters, and each extra interface to be listed consists of minimum
7 characters (in the form "sgi1.0:sgi1.1:...").

I.e., you can't have more than about 25 revisions of a library, and
that is only if you increment the revision number by 1 each time you
do a new release. This is obviously not good enough.


That's the problem, now for my proposed solution:

The thing is that I can't see why we need to pass -set_version at all,
as the default behavior for IRIX ld is to keep compatibility only over
major version numbers -- i.e. the minor number defaults to being
ignored by the runtime linker if the library was created without the
-set_version option.

So unless I've overlooked something crucial, I propose the attached
patch as a workaround for the IRIX ld problem. Changelog entry as
follows (I'm not sure in which format you want patches against release
tarballs, I guess you'd perhaps want to ignore the changes to the
autogenerated files):

2000-10-26  Morten Eriksen  <[EMAIL PROTECTED]>

* ltconfig.in (irix*): Remove unnecessary use of the buggy
-set_version option to IRIX ld (the linker segfaults for
strings longer than ~230 characters).
* ltconfig (irix*): Likewise.
* ltmain.in (irix*): No need to build the $verstring variable
anymore.
* ltmain.sh (irix*): Likewise.

BTW, AFAICS the CVS HEAD-branch also has the same problem.

(I Cc:'ed the discussion mailinglist as I'm not 100% sure this is the
correct solution.)

Regards,
Morten Eriksen



diff -u libtool-1.3.5-org/ltconfig libtool-1.3.5/ltconfig
--- libtool-1.3.5-org/ltconfig  Sat May 27 13:15:00 2000
+++ libtool-1.3.5/ltconfig  Thu Oct 26 15:25:54 2000
@@ -1382,9 +1382,9 @@
 
   irix5* | irix6*)
 if test "$with_gcc" = yes; then
-  archive_cmds='$CC -shared $libobjs $deplibs $linkopts ${wl}-soname ${wl}$soname 
`test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` ${wl}-update_registry 
${wl}${objdir}/so_locations -o $lib'
+  archive_cmds='$CC -shared $libobjs $deplibs $linkopts ${wl}-soname ${wl}$soname 
+${wl}-update_registry ${wl}${objdir}/so_locations -o $lib'
 else
-  archive_cmds='$LD -shared $libobjs $deplibs $linkopts -soname $soname `test -n 
"$verstring" && echo -set_version $verstring` -update_registry ${objdir}/so_locations 
-o $lib'
+  archive_cmds='$LD -shared $libobjs $deplibs $linkopts -soname $soname 
+-update_registry ${objdir}/so_locations -o $lib'
 fi
 hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
 hardcode_libdir_separator=:
diff -u libtool-1.3.5-org/ltconfig.in libtool-1.3.5/ltconfig.in
--- libtool-1.3.5-org/ltconfig.in   Sat May 27 03:58:57 2000
+++ libtool-1.3.5/ltconfig.in   Thu Oct 26 14:17:47 2000
@@ -1382,9 +1382,9 @@
 
   irix5* | irix6*)
 if test "$with_gcc" = yes; then
-  archive_cmds='$CC -shared $libo

Re: mulit-language-branch BUG: circular macro dependencies

[Morten Eriksen]

Pavel Roskin <[EMAIL PROTECTED]> writes:

[...]
> My understanding is that AC_PROG_LIBTOOL in the ml-branch tries to
> fool autoconf and gets caught by the new dependency tracking code.
> 
> Concerning libltdl/configure.in, there is indeed a loop:
> 
> configure.in:36: AC_LTDL_SYMBOL_USCORE is required by...
> ./aclocal.m4:1265: AC_LTDL_DLSYM_USCORE is expanded from...
> ./aclocal.m4:1203: AC_LTDL_SYMBOL_USCORE is expanded from...
> 
> which means that AC_LTDL_SYMBOL_USCORE calls AC_LTDL_DLSYM_USCORE
> which requires AC_LTDL_SYMBOL_USCORE.

I submitted a suggestion for a patch for this just a few days ago. See
attachment.

Regards,
Morten



Index: ChangeLog
===
RCS file: /home/cvs/libtool/ChangeLog,v
retrieving revision 1.809
diff -u -r1.809 ChangeLog
--- ChangeLog   2000/10/02 01:18:16 1.809
+++ ChangeLog   2000/10/12 16:43:57
@@ -1,3 +1,8 @@
+2000-10-12  Morten Eriksen <[EMAIL PROTECTED]>
+
+   * ltdl.m4 (AC_LIB_LTDL, AC_LTDL_SYMBOL_USCORE): Break a circular
+   dependency between AC_LTDL_SYMBOL_USCORE and AC_LTDL_DLSYM_USCORE.
+
 2000-10-02  Gary V. Vaughan  <[EMAIL PROTECTED]>
 
From Bruce Korb <[EMAIL PROTECTED]>
Index: ltdl.m4
===
RCS file: /home/cvs/libtool/ltdl.m4,v
retrieving revision 1.12
diff -u -r1.12 ltdl.m4
--- ltdl.m4 2000/09/16 20:08:07 1.12
+++ ltdl.m4 2000/10/12 16:43:57
@@ -48,6 +48,7 @@
 AC_REQUIRE([AC_LTDL_DLPREOPEN])dnl
 AC_REQUIRE([AC_LTDL_DLLIB])dnl
 AC_REQUIRE([AC_LTDL_SYMBOL_USCORE])dnl
+AC_REQUIRE([AC_LTDL_DLSYM_USCORE])dnl
 ])# AC_LIB_LTDL
 
 # AC_LTDL_ENABLE_INSTALL
@@ -223,7 +224,6 @@
 rm -rf conftest*
 ])
 AC_MSG_RESULT($ac_cv_sys_symbol_underscore)
-AC_LTDL_DLSYM_USCORE
 ])# AC_LTDL_SYMBOL_USCORE
 
 # AC_LTDL_DLSYM_USCORE

Re: [PATCH] Fix for bootstrapping with latest CVS Autoconf

[Morten Eriksen]

Alexandre Oliva <[EMAIL PROTECTED]> writes:

> The only way to do it so that it works with both autoconf 2.13 and
> CVS autoconf, without triggering the warning in CVS autoconf, is
> this (from CVS automake's missing.m4):
> 
>   am_backtick='`'
>   AC_MSG_WARN([${am_backtick}$VAR' ...])

Ok, I see. New (untested) patch attached.

BTW, I noticed something which looks a bit strange to me. Beginning at
approximately line 2180 of libtool.m4 (from the head CVS branch),
there are a lot of shell variables which are set up. But some of them
are just set to their current value, for instance like this:

[...]
# The host system.
host_alias=$host_alias
host=$host
[...]
# A symbol stripping program
STRIP=$STRIP

# Used to examine libraries when file_magic_cmd begins "file"
MAGIC_CMD=$MAGIC_CMD

# Used on cygwin: DLL creation program.
DLLTOOL="$DLLTOOL"

# Used on cygwin: object dumper.
OBJDUMP="$OBJDUMP"

# Used on cygwin: assembler.
AS="$AS"
[...]

..etc, etc. What is the point in doing this?

Regards,
Morten



Index: ChangeLog
===
RCS file: /home/cvs/libtool/ChangeLog,v
retrieving revision 1.809
diff -u -r1.809 ChangeLog
--- ChangeLog   2000/10/02 01:18:16 1.809
+++ ChangeLog   2000/10/11 14:48:12
@@ -1,3 +1,8 @@
+2000-10-12  Morten Eriksen <[EMAIL PROTECTED]>
+
+   * libtool.m4 (_LT_AC_LTCONFIG_HACK): Fix invalid backslash
+   quoting.
+
 2000-10-02  Gary V. Vaughan  <[EMAIL PROTECTED]>
 
From Bruce Korb <[EMAIL PROTECTED]>
Index: libtool.m4
===
RCS file: /home/cvs/libtool/libtool.m4,v
retrieving revision 1.118
diff -u -r1.118 libtool.m4
--- libtool.m4  2000/09/30 05:28:23 1.118
+++ libtool.m4  2000/10/12 10:32:42
@@ -775,10 +775,11 @@
 
 # Check for any special shared library compilation flags.
 if test -n "$ac_cv_prog_cc_shlib"; then
-  AC_MSG_WARN([\`$CC' requires \`$ac_cv_prog_cc_shlib' to build shared libraries])
+  lt_backtick='`' # workaround for "quoted backtick" warning from Autoconf.
+  AC_MSG_WARN([${lt_backtick}$CC' requires ${lt_backtick}$ac_cv_prog_cc_shlib' to 
+build shared libraries])
   if echo "$old_CC $old_CFLAGS " | [egrep -e "[]$ac_cv_prog_cc_shlib[  ]"] 
>/dev/null; then :
   else
-   AC_MSG_WARN([add \`$ac_cv_prog_cc_shlib' to the CC or CFLAGS env variable and 
reconfigure])
+   AC_MSG_WARN([add ${lt_backtick}$ac_cv_prog_cc_shlib' to the CC or CFLAGS env 
+variable and reconfigure])
 ac_cv_prog_cc_can_build_shared=no
   fi
 fi
@@ -886,7 +887,8 @@
   ln conftest.a conftest.b 2>/dev/null && hard_links=no
   AC_MSG_RESULT([$hard_links])
   if test "$hard_links" = no; then
-AC_MSG_WARN([\`$CC' does not support \`-c -o', so \`make -j' may be unsafe])
+lt_backtick='`' # workaround for "quoted backtick" warning from Autoconf.
+AC_MSG_WARN([${lt_backtick}$CC' does not support ${lt_backtick}-c -o', so 
+${lt_backtick}make -j' may be unsafe])
 need_locks=warn
   fi
 else

[PATCH] Fix for bootstrapping with latest CVS Autoconf

[Morten Eriksen]

Hi,

Autoconf straight out of CVS will complain about "backquotes and
doublequotes should not be backslashed" when expanding the macro code
of _LT_AC_LTCONFIG_HACK libtool.m4.

This is against the head branch -- I haven't checked if the 1.3 branch
and/or the multi-language branch should be fixed in the same manner.

BTW, there seems to be many minor problems when bootstrapping libtool
from the head CVS branch with the latest Autoconf and Automake
(i.e. from CVS). Is that supposed to work? If yes, I'll probably give
it a look-over and possibly send a bunch of patches to fix the issues
which pops up.

Regards,
Morten



Index: ChangeLog
===
RCS file: /home/cvs/libtool/ChangeLog,v
retrieving revision 1.809
diff -u -r1.809 ChangeLog
--- ChangeLog   2000/10/02 01:18:16 1.809
+++ ChangeLog   2000/10/11 14:48:12
@@ -1,3 +1,8 @@
+2000-10-11  Morten Eriksen <[EMAIL PROTECTED]>
+
+   * libtool.m4 (_LT_AC_LTCONFIG_HACK): Fix invalid backslash
+   quoting.
+
 2000-10-02  Gary V. Vaughan  <[EMAIL PROTECTED]>
 
From Bruce Korb <[EMAIL PROTECTED]>
Index: libtool.m4
===
RCS file: /home/cvs/libtool/libtool.m4,v
retrieving revision 1.118
diff -u -r1.118 libtool.m4
--- libtool.m4  2000/09/30 05:28:23 1.118
+++ libtool.m4  2000/10/11 14:48:13
@@ -775,10 +775,10 @@
 
 # Check for any special shared library compilation flags.
 if test -n "$ac_cv_prog_cc_shlib"; then
-  AC_MSG_WARN([\`$CC' requires \`$ac_cv_prog_cc_shlib' to build shared libraries])
+  AC_MSG_WARN(['$CC' requires '$ac_cv_prog_cc_shlib' to build shared libraries])
   if echo "$old_CC $old_CFLAGS " | [egrep -e "[]$ac_cv_prog_cc_shlib[  ]"] 
>/dev/null; then :
   else
-   AC_MSG_WARN([add \`$ac_cv_prog_cc_shlib' to the CC or CFLAGS env variable and 
reconfigure])
+   AC_MSG_WARN([add '$ac_cv_prog_cc_shlib' to the CC or CFLAGS env variable and 
+reconfigure])
 ac_cv_prog_cc_can_build_shared=no
   fi
 fi
@@ -886,7 +886,7 @@
   ln conftest.a conftest.b 2>/dev/null && hard_links=no
   AC_MSG_RESULT([$hard_links])
   if test "$hard_links" = no; then
-AC_MSG_WARN([\`$CC' does not support \`-c -o', so \`make -j' may be unsafe])
+AC_MSG_WARN(['$CC' does not support '-c -o', so 'make -j' may be unsafe])
 need_locks=warn
   fi
 else

Re: arg list too long (so, split it into two?)

[Morten Eriksen]

Robert Boehne <[EMAIL PROTECTED]> writes:

> I have a large library that IRIX CC w/ multi-language libtool is not
> happy creating.  It seems that the link line is too much for CC to
> handle.

Sounds familiar.. :^(

> Is the only solution to split this library into convience
> libs, then link those toghether?

I don't think this will help, as any convenience .a-libs will get
extracted into their object-files before the final linking -- IIRC.

Two strategies that have worked for us are:

* change the IRIX-setting for the maximum size of the argument
  list. To do this, log in as root, run ``systune -i'' and set
  the ``ncargs'' variable large enough (I think the default is
  20kB -- trying doubling until you don't get the problem).

  This fix will only work on the machines where you go through
  this routine, of course. And only for the current boot. (To
  make the change permanent for an IRIX-installation, execute
  ``mv /unix.install /unix'' (but don't blame me if something
  goes wrong).)

* make larger and fewer object-files, by using some small
  number of sourcefiles to include the "real" sourcefiles by
  "#include" statements, and compile and link these instead.

  For an example of how this can be done and integrated as a
  configure and build-option, see the Coin library at
  .


Note that another platform with the problem you describe is AIX, where
the former suggestion for solution won't work -- the argument size
limit is actually hardcoded into the OS.  :^/

If anyone on the list has any other suggestions for solving Robert's
problem, I would be very interested to hear about them. Is it for
instance possible to solve it fundamentally in libtool by adding a
workaround for the platforms with low default argument size setting?

Regards,
Morten

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

Bug with AC_CHECK_LIBM

[Morten Eriksen]

Hi,

I believe I've found a bug with this macro in Libtool.

When the current compiler is SGI MIPSpro CC v7.30 (this is a C++
compiler, BTW), using AC_CHECK_LIB with "main" as the function to look
for will never work. I.e.:

AC_CHECK_LIB($libname, main)

..always gives a false result -- no matter the value of $libname -- as
the SGI CC compiler will complain with (snipped from config.log):

== snip start =

cc-1364 CC: ERROR File = configure, Line = 912
  The function "main" cannot be called or have its address taken.

  main()
  ^

1 error detected in the compilation of "conftest.c".
configure: failed program was:
#line 909 "configure"
#include "confdefs.h"

int main() {
main()
; return 0; }

== snip end ==

I tried patching it to use sin() instead, but that won't work either,
as the C++ compiler and/or linker want the function signature in the
testcode to match the actual signature.

I wrote a completely new math library check instead, which I of course
would be more than willing to submit as a replacement for
AC_CHECK_LIBM, if this sounds like a good idea.

If anyone of the libtool maintainers want to give it a look-over:

cvs -d :pserver:[EMAIL PROTECTED]:/export/cvsroot login
CVS password:(use "cvs")
cvs -d :pserver:[EMAIL PROTECTED]:/export/cvsroot checkout conf-macros
more conf-macros/check_mathlib.m4


Regards,
Morten Eriksen