RE: Version numbering change on IRIX
Title: RE: Version numbering change on IRIX Steve, IMHO it isn't worth the bother to allow both, I'll just revert patch. Everyone agree? Robert -Original Message- From: Steve M. Robbins [mailto:[EMAIL PROTECTED]] Sent: Friday, November 15, 2002 8:21 PM To: Boehne, Robert; [EMAIL PROTECTED] Subject: Re: Version numbering change on IRIX On Fri, Nov 15, 2002 at 05:34:33PM +0100, Rainer Orth wrote: > Robert, > > > This change was a long time coming, so many people have complained > > about having libx.so.1 under Solars/Linux and having libx.so.2 under IRIX. > > Adding 1 to the version isn't necessary, I've looked everywhere I could > > think of to find out why this was done in the first place, but found > > none. I realize this change doesn't "fix" anything, and could potentially > > cause problems, but these will be transient, and it is consistent with > > other platforms. > > indeed: breaking every application linked against the old (overwritten) > version of affected libraries is certainly a problem. This will be > transient since people will be forced to rebuild/relink every affected > application; something I consider a nightmare in big installations, > especially when libraries used all over the place (like the GCC runtime > libraries) are affected. > > I can already hear the outcry from affected users and admins; I don't want > to be in the position to explain to them that their applications had to be > broken for cosmetic reasons and consistency with other platforms. I think Rainer has a point. This change shouldn't be made lightly. Perhaps the "add 1 for IRIX" behaviour could be made a libtool option that is ON by default? -S
cross-compiling several dependent libraries
Hi all, I am confronted with a problem which is already known. But I didn't find a solution yet. BTW, is there a way to _search_ the GNU mailing-list archives? I found exactly the same problem described here: http://www.linuxsh.st.com/getting_started/gtk2_cross_compile.php3#glib_target I'm using autoconf 2.53, automake 1.5 and libtool 1.4.2a. I'd like to cross-compile (arm-linux) several packages a, b... which depend on library x. cross-compiling x is no problem. Package a, b... depend on x. So there is a AC_CHECK_LIB(x, func,,,) in configure.ac. When I start configure with --build=i686 --host=arm-linux --exec-prefix=somewhere the cross-compiling mode is activated and libx is found by arm-linux-gcc. OK. But when it's time to relink .libs/liba.so.0.0.0 arm-gcc-linux is told to link with /usr/local/lib/libx.so which obviously is the pc version. arm-gcc-linux understandably refuses to link... This is a libtool bug, right? Am I missing anything? Does a newer version of libtool fix this bug? BW, Jan -- Jan WeilFraunhofer weil at hhi dot de Institut Nachrichtentechnik (+49 30) 3 10 02 - 8 76 Heinrich-Hertz-Institut ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Maintainership
On Mon, 18 Nov 2002, Akim Demaille wrote: > > Bob> Rumor has it that libtool still works with Autoconf 2.13. It would be > Bob> wise not to intentionally break compatability with Autoconf 2.13. > Bob> However, I only test with the most current releases of Autoconf. > > It has once been suggested that 1.4.5 be the last 2.13 compatible > version. Has this changed? I am switching this discussion from [EMAIL PROTECTED] to [EMAIL PROTECTED] since that is where a discussion like this belongs. While I have no personal interesting in supporting Autoconf 2.13, I believe that it is in libtool's best interest to remain compatable (at least for a while) with Autoconf 2.13 since to do otherwise would result in the entrenched Autoconf 2.13 community sticking with Libtool 1.4.X, and never advancing to Libtool 1.5. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering change on IRIX
Robert, > IMHO it isn't worth the bother to allow both, I'll just revert patch. > Everyone agree? certainly :-) If the difference in shlib version numbering between Solaris/Linux and IRIX is really a FAQ that causes user confusion, perhaps this should be documented? Rainer ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
CVS libtool package issues
There are a number CVS libtool package issues which should be addressed before libtool 1.5 is released. 1) 'make distclean' does not work unless 'make test' has been performed since otherwise there are no Makefiles in the test directory. 2) Under Solaris, 'make test' somehow runs the tests in the background such that CONTROL-C kills the parent make, but the tests continue to run in the background and there seems to be no way to stop them other than rebooting the machine or waiting for them to complete by themselves. 3) The Makefile.am files used by the libtool demos are not compatable with any version of Automake newer than 1.6.2 due to this error: Makefile.am: object `longer_file_name_hello.lo' created both with libtool and without Makefile.am: object `longer_file_name_foo.lo' created both with libtool and without 4) With Autoconf 2.56 and Automake 1.7.1, automake fails with the error: tests/Makefile.am:73: FFLAGS was already defined in condition TRUE, which implies condition HAVE_F77_TRUE ... configure.ac:111: ... `FFLAGS' previously defined here. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: CVS libtool package issues
There are a number CVS libtool package issues which should be
addressed before libtool 1.5 is released.
Also, check the 'In the Near Term" section here:
http://www.gnu.org/software/libtool/future.html
Of the four bullet points, AFAIK only one ("Robert Collins...") has
actually been achieved.
1) 'make distclean' does not work unless 'make test' has
been performed since otherwise there are no Makefiles
in the test directory.
Dunno. I always run make check.
3) The Makefile.am files used by the libtool demos are not
compatable with any version of Automake newer than 1.6.2
due to this error:
Makefile.am: object `longer_file_name_hello.lo' created both with
libtool and without
Makefile.am: object `longer_file_name_foo.lo' created both with
libtool and without
4) With Autoconf 2.56 and Automake 1.7.1, automake fails with the
error:
tests/Makefile.am:73: FFLAGS was already defined in condition TRUE,
which implies condition HAVE_F77_TRUE ...
configure.ac:111: ... `FFLAGS' previously defined here.
Are you sure? I've seen both messages, but I always thought they were
warnings, not errors. I had no problems building and testing, even
after the appearance of those messages. (cygwin-over-w2k)
--Chuck
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: CVS libtool package issues
On Mon, 18 Nov 2002, Charles Wilson wrote:
> Also, check the 'In the Near Term" section here:
> http://www.gnu.org/software/libtool/future.html
> Of the four bullet points, AFAIK only one ("Robert Collins...") has
> actually been achieved.
This page seems to be rather out of date.
> > 3) The Makefile.am files used by the libtool demos are not
> > compatable with any version of Automake newer than 1.6.2
> > due to this error:
> >
> > Makefile.am: object `longer_file_name_hello.lo' created both with
> > libtool and without
> > Makefile.am: object `longer_file_name_foo.lo' created both with
> > libtool and without
> >
> > 4) With Autoconf 2.56 and Automake 1.7.1, automake fails with the
> > error:
> >
> > tests/Makefile.am:73: FFLAGS was already defined in condition TRUE,
> > which implies condition HAVE_F77_TRUE ...
> > configure.ac:111: ... `FFLAGS' previously defined here.
>
>
> Are you sure? I've seen both messages, but I always thought they were
> warnings, not errors. I had no problems building and testing, even
> after the appearance of those messages. (cygwin-over-w2k)
It is not always clear what is a warning and what is an error,
regardless, libtool should work cleanly with the Autoconf & Automake
which are current at the time of release.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: CVS libtool package issues
Bob Friesenhahn wrote:
Also, check the 'In the Near Term" section here:
http://www.gnu.org/software/libtool/future.html
Of the four bullet points, AFAIK only one ("Robert Collins...") has
actually been achieved.
This page seems to be rather out of date.
Okay, but it duplicates a lot of what is in the TODO file (speaking of
which, TODO needs a housecleaning...)
It is not always clear what is a warning and what is an error,
regardless, libtool should work cleanly with the Autoconf & Automake
which are current at the time of release.
Fair enough.
--Chuck
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
