Re: Link flags that get ignored

[Tim Mooney]

In regard to: Link flags that get ignored, Josep M. Perez Cancer said (at...:

>I am using libtool to create a library on mips-sgi-irix6.5 with the following
>constraints:
>
>CC=cc  (The platform C compiler)
>CFLAGS=-64 (64 bits)
>CXX=CC (The platform C++ compiler)
>CXXFLAGS=-LANG:std -64 (C++ conformity flag and 64 bits)
>LDFLAGS=-64(64 bits)
>
>Libtool doesn't pass the -64 argument to the linker, and then I can't create a
>64 bit library. I have had the same problem with other architectures
>before. Is there any way I can make it not ignore the flag?

What happens if you go completely around libtool, and set SGI_ABI before
you invoke libtool (and then don't pass -64 to anything via CC/CFLAGS
etc.)?

See the ABI(5) man page for more information.

Also, whether or not that works, what happens if you instead do:

CC='cc -64 -Wl,-64'
CXX='CC -64 -Wl,-64'
CXXFLAGS='-LANG:std'
LDFLAGS='-64'

Do either of these work around the problem successfully?

Ideally libtool should be passing the link flags unmolested, but it's not
(yet) perfect.

Tim
-- 
Tim Mooney  [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building  (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


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

[fehrin@t-online.de: libtool versus gcj]

[Dr. Franz Fehringer]

Second try, first one did not get through.

- Forwarded message from "Dr. Franz Fehringer" <[EMAIL PROTECTED]> -

Date: Mon, 8 Mar 2004 14:34:34 +0100
From: "Dr. Franz Fehringer" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: libtool versus gcj
User-Agent: Mutt/1.3.22.1i

Hello,

I observe the following problem with libtool 1.5.2 and with gcc/g++/gcj 3.3.3
installed:
The gcj related tests all fail

checking if gcj PIC flag -fPIC works... no
checking if gcj supports -c -o file.o... no

On further inspection it turns out, that gcj is apparently invoked as
$GCJ $CFLAGS $CPPFLAGS
instead of
$GCJ $GCJFLAGS
The output in config.log reads

gcj -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_REENTRANT -I/usr/local/include/ncurses 
-I/usr/local/ActivePython-2.3/include -pipe -pthread -O3 -fomit-frame-pointer 
-ffast-math -march=k6 -m3dnow -mmmx -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_REENTRANT 
-I/usr/local/include/ncurses -I/usr/local/ActivePython-2.3/include -fPIC conftest.java
gcj: can't specify `-D' without `--main'

My environment is

export PATH=/usr/local/gcc/bin:$PATH
export MANPATH=/usr/local/gcc/man:$MANPATH
export INFOPATH=/usr/local/gcc/info:$INFOPATH
export INFODIR=/usr/local/gcc/info:$INFODIR
export CC=gcc
export CXX=g++
export GCJ=gcj
export CPPFLAGS="-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_REENTRANT 
-I/usr/local/include/ncurses -I/usr/local/ActivePython-2.3/include"
export PICFLAGS="-fPIC -DPIC"
export FLAGS="$CPPFLAGS -pipe -pthread -O3 -fomit-frame-pointer -ffast-math -march=k6 
-m3dnow -mmmx"
export CFLAGS="$FLAGS"
export LIBCFLAGS="$CFLAGS $PICFLAGS"
export CXXFLAGS=$FLAGS
export LIBCXXFLAGS="$CXXFLAGS $PICFLAGS"
export GCJFLAGS="-pipe -pthread -Wp,-D_REENTRANT -Wp,-D_GNU_SOURCE 
-Wp,-D_FILE_OFFSET_BITS=64 -O2 -fexpensive-optimizations -ffast-math -march=k6 -m3dnow 
-mmmx"
export LDFLAGS="-O3 -Wl,-O3 -L/usr/local/lib -L/usr/X11R6/lib -lrt -lpthread -lutil"
export LD_RUN_PATH=/usr/local/lib
export AR_FLAGS=crs

This is on a SuSE 7.3 (AMD 32bit) Installation.

One minor glitch:

checking whether we are using the GNU Fortran 77 compiler... no
checking whether  accepts -g... no
.
.
.
appending configuration tag "F77" to libtool

Shouldn't the second line/test omitted, if there is no Fortran compiler found?
And why tag "F77" without Fortran compiler?

Greetings

Franz


- End forwarded message -


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

Re: Suggestion

[Rob Wyrick]

Libtool doesn't use DESTDIR The makefiles (autoconf/automake) use 
DESTDIR.
When the *.la files are built, libtool puts a line like
   libdir=/some/path/to/a/lib/dir
in it.  Then, when you try to install via 'make install'  which, in turn 
call libtool --mode=install
libtool will refuse to install into any directory EXCEPT what was 
specified in the .la file.
It breaks, therefore, if you try to use DESTDIR= or prefix= arguments to 
the 'make install'
command.

-Rob

Bob Friesenhahn wrote:

On Fri, 12 Mar 2004, Robert Wyrick wrote:

 

I'm developing a package manager that aids users in installing
sofware (from source) into their home directories.  Packages
are managed in a way VERY MUCH like GNU stow.  The significant
feature of stow (and my package manager) is that there is a
distinction between runtime directories and install directories.
I've noticed that some packages that utilize libtool have
problems with this because libtool has checks that make it
refuse to install libraries into a directory that doesn't
start with the location it was informed of at "configure"
time.  libtool has no concept of separate runtime/install
time directories.
   

Libtool uses the DESTDIR environment variable to support this.

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



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

Re: Suggestion

[Bob Friesenhahn]

On Fri, 12 Mar 2004, Rob Wyrick wrote:

> Libtool doesn't use DESTDIR The makefiles (autoconf/automake) use
> DESTDIR.
> When the *.la files are built, libtool puts a line like
> libdir=/some/path/to/a/lib/dir
> in it.  Then, when you try to install via 'make install'  which, in turn
> call libtool --mode=install
> libtool will refuse to install into any directory EXCEPT what was
> specified in the .la file.
> It breaks, therefore, if you try to use DESTDIR= or prefix= arguments to
> the 'make install'
> command.

What version of libtool are you using?  A DESTDIR install certainly
works with the version of libtool that I am using.  Libtool does the
install, but it warns that 'libtool --finish' should be used when the
libraries are copied to their intended location.

There was a time when this was not so.

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



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

Re: Suggestion

[Bob Friesenhahn]

On Fri, 12 Mar 2004, Robert Wyrick wrote:

> I'm developing a package manager that aids users in installing
> sofware (from source) into their home directories.  Packages
> are managed in a way VERY MUCH like GNU stow.  The significant
> feature of stow (and my package manager) is that there is a
> distinction between runtime directories and install directories.
>
> I've noticed that some packages that utilize libtool have
> problems with this because libtool has checks that make it
> refuse to install libraries into a directory that doesn't
> start with the location it was informed of at "configure"
> time.  libtool has no concept of separate runtime/install
> time directories.

Libtool uses the DESTDIR environment variable to support this.

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



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

Problems installing dependant libraries

[Fredrick Meunier]

Hi,
I have just come across the same problem raised in the thread "Library 
dependencies & make install" on the automake lists in January this year 
() in a 
reasonably large project.

The last message in the thread from Alexandre Duret-Lutz suggests:
"Another idea is to split the installation procedure in two
steps: copy all libraries, and once it is done relink all
libraries.  Would that work?  If so, we need a way to tell
libtool to copy libraries without relinking."
I think the answer is yes, that would work. Are there any prospects of 
this being addressed?

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

Re: Problems installing dependant libraries

[Bob Friesenhahn]

On Fri, 12 Mar 2004, Fredrick Meunier wrote:

> Hi,
> I have just come across the same problem raised in the thread "Library
> dependencies & make install" on the automake lists in January this year
> () in a
> reasonably large project.
>
> The last message in the thread from Alexandre Duret-Lutz suggests:
> "Another idea is to split the installation procedure in two
> steps: copy all libraries, and once it is done relink all
> libraries.  Would that work?  If so, we need a way to tell
> libtool to copy libraries without relinking."

The fundamental problem is that Automake does not have an overall
coherent understanding of the library dependencies when libraries are
built using a recursive build.  Without understanding the library
dependencies, it is difficult to see how relinking would work.

Relinking the libraries using an arbitrary order is unlikely to work
even if all the libraries are present since then the wrong embedded
library dependencies (for systems which support the notion) may be
picked up.

It seems that libtool already avoids relinking for DESTDIR installs,
and expects the user to use 'libtool --finish' at install time (a step
which is usually forgotten).  That means that libtool already
understands how to do a delayed relink.

So the solution is for someone to come up with a way that Automake can
have a coherent understanding of library dependencies (which are
already specified piecemeal in individual Makefile.am files).  One way
to accomplish this may be to maintain a top-level file which records
the order that libraries were linked during the build.

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



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