Kean Johnston | 4 Aug 20:55 2002

Please help with OSR5 port?

Hello,

I am trying to get libtool to work propperly (as defined by me :-)) on
SCO OpenServer. Even with the latest version out of CVS, there are
still some make check failures (mdemo-exec, mdemo-inst, tagdemo-exec etc).
On top of that, for 5.0.7, I have dramatically changed the link editor and
RTLD to be the same as on OpenUNIX 8. However, even that systems libtool
configuration is, I believe, a little wrong. So, what I will do here
is describe the characteristics of ld and the RTLD, the compiler options
used to create shared libraries, and how I'd like to see things end up.
Hopefully then, someone on this list with more experience of the twisty
maze of libtool variables can help me set things up correctly. Note that
although I believe the same strategy should apply to OpenUNIX 8, please
lets focus on OpenServer, as thats what I have an immediate need to get
working. I can fuss with OU8 later.

Please also note that things as described here refer to the as-yet-unreleased
SCO OpenServer 5.0.7. But all of these characteristics will be available on
previous releases, via a supplement. Having just said that though, the
scheme I propose wont matter a jot, it doesnt rely on the new RTLD or ld
characteristics. But they are defined here for your reference.

ELF Link Editor (ld) characteristics:
  ld -R path
     Inserts PATH as a DT_RUNPATH entry in either a shared library or an
     ELF executable. PATH can be a colon-separated list of directories.
     See RTLD characteristics below to see how DT_RUNPATH is used.

  ld -h path
     Inserts PATH as an SONAME entry in a shared library. PATH is a single
(Continue reading)

Karl Chen | 8 Aug 03:38 2002

bug in cvs libtool tag detection for same-basename compilers

Hi, I believe there is a bug in libtool (current cvs) for "TAG" detection.

libtool decides which compiler flags to use based on the command line by 
checking the basename of the command-line command and the basename of each 
tag's command. I'm sure you already know that, just making sure we're on 
the same page.

This works for "gcc" and "g++" and "g77" but it doesn't work in a lot of 
other cases. Examples:
     KAI C++:
         "KCC" is a C++ compiler but "KCC --c" is a C compiler. There is no 
command for just C.

     gcc:
          "gcc" is a C compiler as well as C++  and other compiler 
(depending on file extension), although people usually use g++ for C++ just 
to simplify linking. Also "gcc -x c++" is a C++ compiler but that is a 
little contrived anyway.

If I have CC="KCC --c" and CXX="KCC", then libtool will not compile C++ 
programs because it will look at the command line, see "KCC", compare to 
the first tag which happens to be C, whose base commandname is "KCC", and 
decide to compile it as a C program.

One possible more-robust fix using automake is to use "--tag=CXX" to the 
libtool C++ command-line in LTCXX (or whatever); similar for other languages.

Currently I'm kludging around it by having autoconf create a script 
"KCC--c" which just contains a call to "${CXX} --c \"\${ <at> }\"", and set 
CC=KCC--c if "$CC"="$CXX --c".
(Continue reading)

Bruno Haible | 8 Aug 16:18 2002
Picon

Re: Bug#155610: gettext fails to build from source (fwd)

Santiago Vila reports a libtool 1.4.2 problem occurring on Linux/m68k
with the gettext package:

> FYI:
> 
> On a Linux m68k system without the file command installed, a build of gettext
> fails to create the shared libraries.
> 
> This is because gettext contains a libtool.m4 file saying:
> 
> # This must be Linux ELF.
> linux-gnu*)
>   case $host_cpu in
>   alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* )
>     lt_cv_deplibs_check_method=pass_all ;;
>   *)
>     # glibc up to 2.1.1 does not perform some relocations on ARM
>     lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[LM]]SB (shared object|dynamic
lib )' ;;
>   esac
>   lt_cv_file_magic_test_file=`echo /lib/libc.so* /lib/libc-*.so`
>   ;;
> 
> which is also the source of several problems (see
> http://bugs.debian.org/120515).
> 
> Debian uses glibc-2.2 already, so I will probably patch libtool.m4 so
> that it always uses pass_all under Linux, as it was done in the Debian
> libtool package.
> 
(Continue reading)

Tom Tromey | 14 Aug 18:07 2002
Picon

Re: bug in cvs libtool tag detection for same-basename compilers

>>>>> "Karl" == Karl Chen <quarl <at> llnl.gov> writes:

Karl> One possible more-robust fix using automake is to use
Karl> "--tag=CXX" to the libtool C++ command-line in LTCXX (or
Karl> whatever); similar for other languages.

I believe there is already an automake PR for this problem.

Tom
Joshua Weage | 14 Aug 18:37 2002
Picon

Link problem on HP-UX 11.00

I'm having problems with libtool in the glib-2.0.1 package.  I'm on
HP-UX 11.00 with the HP ANSI C compiler.  The installed copies of
libgobject, libgthread and libgmodule are linked to libglib located in
the source directory, not the installed location.

I brought this to the attention of the glib developers and they think
it is a libtool problem.

config.guess reports:  hppa2.0w-hp-hpux11.00

Joshua Weage

=====
--
--  <http://origin.me.gatech.edu/~weage>    --
--  <http://members.xoom.com/joshua_weage>  --
--  <http://weage.freeservers.com/>         --

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
Patrick Welche | 19 Aug 19:52 2002
Picon
Picon

Re: mdemo test failure

On Mon, Jul 29, 2002 at 09:43:45AM +0100, Nick Hudson wrote:
> On Friday 26 July 2002 9:44 pm, Patrick Welche wrote:
> > On NetBSD-1.6D/i386, with today's cvs libtool in tests:
> > 
> > gmake MAKE=gmake TESTS="mdemo-static.test mdemo-make.test mdemo-exec.test" 
> VERBOSE=-x check
> > 
> > gives:

=== Running mdemo-exec.test
Executing uninstalled programs in ../mdemo
Welcome to GNU libtool mdemo!
filename: foo1.a  pwd: /usr/src/local/libtool/tests
can't open the module ../mdemo/foo1.la!
error was: file not found
filename: libfoo2.a  pwd: /usr/src/local/libtool/tests
can't open the module ../mdemo/libfoo2.la!
error was: file not found
myfunc returned: 57616
myfunc is ok!
./mdemo-exec.test: execution of ../mdemo/mdemo_static failed
Welcome to GNU libtool mdemo!
filename: foo1.a  pwd: /usr/src/local/libtool/tests
can't open the module ../mdemo/foo1.la!
error was: file not found
filename: libfoo2.a  pwd: /usr/src/local/libtool/tests
can't open the module ../mdemo/libfoo2.la!
error was: file not found
myfunc returned: 57616
myfunc is ok!
(Continue reading)

David Murphy | 21 Aug 20:02 2002
Picon

Bug in config.guess on AIX


In config.guess GNU config.guess (2001-09-04) there is a simple problem with identification of IBM's POWER processors.  I have checked and the problem exists in the current working archive too.

The problem is due to an extra space in a grep statement, that is grep ' POWER' instead of grep 'POWER' when determining the result of a test for which processor.

review line 510 of above config.guess

The test for processor   /usr/sbin/lsattr -El ${IBM_CPU_ID}  returns

state     enable         Processor state False
type      PowerPC_POWER3 Processor type  False
frequency 333000000      Processor Speed False

but the test
  if /usr/sbin/lsattr -El ${IBM_CPU_ID} | grep ' POWER' >/dev/null 2>&1;
then
      IBM_ARCH=rs6000
   else
      IBM_ARCH=powerpc

will return powerpc rather than rs6000.

Older version of config.guess performed grep POWER

Hence this is a simple fix to make (remove the space), with the test being easily demonstrated  by the /usr/sbin/lsattr command and running config.guess itself.

The corrected config.guess should return

rs6000-ibm-aix5.0.0.0

on the current AIX 5L platform running on a RS6000 and not the currently incorrect

powerpc-ibm-aix5.0.0.0

Please contact me if you need further details or assistance.

David Murphy dmurphy <at> novell.com
 
Boehne, Robert | 21 Aug 20:50 2002

RE: Bug in config.guess on AIX

config.guess is not part of Libtool, read config.guess to find where to submit support requests.
 
HTH,
 
Robert
-----Original Message-----
From: David Murphy [mailto:DMURPHY <at> novell.com]
Sent: Wednesday, August 21, 2002 1:03 PM
To: bug-libtool <at> gnu.org
Subject: Bug in config.guess on AIX


In config.guess GNU config.guess (2001-09-04) there is a simple problem with identification of IBM's POWER processors.  I have checked and the problem exists in the current working archive too.

The problem is due to an extra space in a grep statement, that is grep ' POWER' instead of grep 'POWER' when determining the result of a test for which processor.

review line 510 of above config.guess

The test for processor   /usr/sbin/lsattr -El ${IBM_CPU_ID}  returns

state     enable         Processor state False
type      PowerPC_POWER3 Processor type  False
frequency 333000000      Processor Speed False

but the test
  if /usr/sbin/lsattr -El ${IBM_CPU_ID} | grep ' POWER' >/dev/null 2>&1;
then
      IBM_ARCH=rs6000
   else
      IBM_ARCH=powerpc

will return powerpc rather than rs6000.

Older version of config.guess performed grep POWER

Hence this is a simple fix to make (remove the space), with the test being easily demonstrated  by the /usr/sbin/lsattr command and running config.guess itself.

The corrected config.guess should return

rs6000-ibm-aix5.0.0.0

on the current AIX 5L platform running on a RS6000 and not the currently incorrect

powerpc-ibm-aix5.0.0.0

Please contact me if you need further details or assistance.

David Murphy dmurphy <at> novell.com
 
David Murphy | 21 Aug 21:22 2002
Picon

RE: Bug in config.guess on AIX

 
 
 dmurphy <at> novell.com


>>> "Boehne, Robert" <robert.boehne <at> ricardo-us.com> 8/21/02 12:50:20 PM >>>
config.guess is not part of Libtool, read config.guess to find where to submit support requests.
 
HTH,
 
Robert
-----Original Message-----
From: David Murphy [mailto:DMURPHY <at> novell.com]
Sent: Wednesday, August 21, 2002 1:03 PM
To: bug-libtool <at> gnu.org
Subject: Bug in config.guess on AIX


In config.guess GNU config.guess (2001-09-04) there is a simple problem with identification of IBM's POWER processors.  I have checked and the problem exists in the current working archive too.

The problem is due to an extra space in a grep statement, that is grep ' POWER' instead of grep 'POWER' when determining the result of a test for which processor.

review line 510 of above config.guess

The test for processor   /usr/sbin/lsattr -El ${IBM_CPU_ID}  returns

state     enable         Processor state False
type      PowerPC_POWER3 Processor type  False
frequency 333000000      Processor Speed False

but the test
  if /usr/sbin/lsattr -El ${IBM_CPU_ID} | grep ' POWER' >/dev/null 2>&1;
then
      IBM_ARCH=rs6000
   else
      IBM_ARCH=powerpc

will return powerpc rather than rs6000.

Older version of config.guess performed grep POWER

Hence this is a simple fix to make (remove the space), with the test being easily demonstrated  by the /usr/sbin/lsattr command and running config.guess itself.

The corrected config.guess should return

rs6000-ibm-aix5.0.0.0

on the current AIX 5L platform running on a RS6000 and not the currently incorrect

powerpc-ibm-aix5.0.0.0

Please contact me if you need further details or assistance.

David Murphy dmurphy <at> novell.com
 

Gmane