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

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".

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.
> 

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

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

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!

Bug in config.guess on AIX

RE: Bug in config.guess on AIX

RE: Bug in config.guess on AIX