[sr #109514] ltmain.sh: [_MSC_VER] should be [_WIN32] in one place

Update of sr #109514 (group libtool): Open/Closed:Open => Closed ___ Follow-up Comment #1: Thank you! A similar patch was submitted and applied [1]. [1] https://savannah.gnu.org/patch/inde

Re: [sr #109844] Do not override user's LD_LIBRARY_PATH in generated ltmain.sh for the build dir wrappers

anonymous wrote: URL: <https://savannah.gnu.org/support/?109844> Summary: Do not override user's LD_LIBRARY_PATH in generated ltmain.sh for the build dir wrappers Project: GNU Libtool Submitted by: None Submitted on:

[sr #109844] Do not override user's LD_LIBRARY_PATH in generated ltmain.sh for the build dir wrappers

URL: <https://savannah.gnu.org/support/?109844> Summary: Do not override user's LD_LIBRARY_PATH in generated ltmain.sh for the build dir wrappers Project: GNU Libtool Submitted by: None Submitted on: Sat 13 Jul 2019 09:5

[sr #109514] ltmain.sh: [_MSC_VER] should be [_WIN32] in one place

URL: <http://savannah.gnu.org/support/?109514> Summary: ltmain.sh: [_MSC_VER] should be [_WIN32] in one place Project: GNU Libtool Submitted by: None Submitted on: Mon 04 Jun 2018 02:21:41 PM UTC Category

Re: Why does ltmain.sh::temp_rpath not need the same system lib considerations?

On Thu, 16 Feb 2017, Nish Aravamudan wrote: I do not believe so, the tests (heimdal self-tests) are run via a Makefile target which calls the generated wrapper script(s). Normally if you call the generated wrapper scripts, things should be ok, as long as the linkage was correct in the first p

Re: Why does ltmain.sh::temp_rpath not need the same system lib considerations?

m > > or equivalent to assure that ./testprogram is executed with correct library > paths? I do not believe so, the tests (heimdal self-tests) are run via a Makefile target which calls the generated wrapper script(s). > > It seems like there is rarely, if ever, a case to put a system l

Re: Why does ltmain.sh::temp_rpath not need the same system lib considerations?

pt, and in particular, it seems like ltmain.sh actually detects adding the system path to compile_rpath and finalize_rpath. Is it correct to do the same elision in temp_rpath? e.g. Without studying the details, it is worth noting that other software delivering libraries does manage to successfull

Why does ltmain.sh::temp_rpath not need the same system lib considerations?

er, a case to put a system library path before a non-system library path in the wrapper script, and in particular, it seems like ltmain.sh actually detects adding the system path to compile_rpath and finalize_rpath. Is it correct to do the same elision in temp_rpath? e.g. --- a/ltmain.sh +++ b

Re: what & where is this file --- ltmain.sh

On 29 Mar 2013, at 23:40, allan George wrote: > Hi, > > what & where is this file --- ltmain.sh ? It is the non-declarative part of libtool. When installed libtool contains the text of ltmain.sh. Please RTFM for more details -- unfortunately autotools still requires a ton of

what & where is this file --- ltmain.sh

Hi, what & where is this file --- ltmain.sh ? It is hiding actual libtool installed ? i have installed 2.4.2 version for libtool :--- ftp://ftp.gnu.org/gnu/libtool/libtool-2.4.2.tar.gz After installing 2.4.2 version of libtool, If i run whereis command, i get following output : /pi/lib

Re: [RFC] Moving ltmain.sh and libtool.m4 into Automake

Hello Mr. Strike, On Oct 18, 2012, at 7:16 PM, NightStrike wrote: > On Wed, Oct 17, 2012 at 11:27 AM, Gary V. Vaughan wrote: >> Thanks to everyone for your feedback. Much appreciated. >> >> It seems that merging libtool into Automake would be an unpopular move all >> around, with significant d

Re: [RFC] Moving ltmain.sh and libtool.m4 into Automake

t; internals, but I don't see any really good alternative to having that > code inside the libtool script. I haven't worked through the actual implementation yet, though I recently pushed some patches that move ltmain.sh/libtool into the same pluggable framework that my bootstrap scri

Re: [RFC] Moving ltmain.sh and libtool.m4 into Automake

On Wed, Oct 17, 2012 at 11:27 AM, Gary V. Vaughan wrote: > Thanks to everyone for your feedback. Much appreciated. > > It seems that merging libtool into Automake would be an unpopular move all > around, with significant downsides for users, so I no longer plan to do > that... unless there is a s

Re: [RFC] Moving ltmain.sh and libtool.m4 into Automake

ine with a direct libtool invocation, or from Makefile.am > specifications. I'm considering splitting the current libtool project > in two: > > 1. libltdl as a standalone runtime loader wrapper > 2. libtool.m4/ltmain.sh to generate the libtool script > > I think (2) belo

Re: [RFC] Moving ltmain.sh and libtool.m4 into Automake

On 17/10/2012 08:27, Gary V. Vaughan wrote: >> > Creading a stand-alone libltdl package is a very good idea. > The separation will also make both packages much smaller and more manageable, > especially without all the contortions of trying to support all the different > ways of copying everything i

Re: [RFC] Moving ltmain.sh and libtool.m4 into Automake

Thanks to everyone for your feedback. Much appreciated. It seems that merging libtool into Automake would be an unpopular move all around, with significant downsides for users, so I no longer plan to do that... unless there is a still strong technical argument supporting it that I've yet to hear.

Re: [RFC] Moving ltmain.sh and libtool.m4 into Automake

On Wed, 17 Oct 2012, Gary V. Vaughan wrote: Libtool is just (a complicated) compiler wrapper, to make building and linking against libraries easy to specify... be that on the command line with a direct libtool invocation, or from Makefile.am specifications. I'm considering splitting the current

Re: [RFC] Moving ltmain.sh and libtool.m4 into Automake

On Wed, 2012-10-17 at 16:41 +0700, Gary V. Vaughan wrote: > Another consideration is that rolling Libtool into Automake would make > using Libtool as a standalone script rather more difficult. Having > said that, my impression is that Libtool is rarely used that way in > any case, and further simp

Re: [RFC] Moving ltmain.sh and libtool.m4 into Automake

On 17/10/12 05:41, Gary V. Vaughan wrote: > Another consideration is that rolling Libtool into Automake would make > using Libtool as a standalone script rather more difficult. Having > said that, my impression is that Libtool is rarely used that way in > any case, and further simplification may b

Re: [RFC] Moving ltmain.sh and libtool.m4 into Automake

On 10/17/2012 11:41 AM, Gary V. Vaughan wrote: > 1. libltdl as a standalone runtime loader wrapper > 2. libtool.m4/ltmain.sh to generate the libtool script While I don't care about such a split in general, ... > I think (2) belongs better into Automake alongside the other tool

Re: [RFC] Moving ltmain.sh and libtool.m4 into Automake

7;m considering splitting the current libtool project > in two: > > 1. libltdl as a standalone runtime loader wrapper > 2. libtool.m4/ltmain.sh to generate the libtool script > > I think (2) belongs better into Automake alongside the other tool > wrappers it already carri

[RFC] Moving ltmain.sh and libtool.m4 into Automake

e loader wrapper 2. libtool.m4/ltmain.sh to generate the libtool script I think (2) belongs better into Automake alongside the other tool wrappers it already carries, where it can decide whether to run the libtool m4 macros and roll an appropriate compiler wrapper tailored for the project using it (n

Re: Removing multiple copies of ltmain.sh

On Sat, 13 Jun 2009, Sam Varshavchik wrote: Libtool no longer uses a ltmain.sh file so maybe using a modern version is the answer to this problem. The latest version that's available for download is 2.2.6a, and I'm running 2.2.6. I built 2.2.6a and installed it in a BUILDROOT (so

Re: Removing multiple copies of ltmain.sh

Bob Friesenhahn writes: On Sat, 13 Jun 2009, Sam Varshavchik wrote: Can anyone suggest a clean way to eliminate all those copies of ltmain.sh. I can always hack up a hook that replaces them with hardlinks, before the tarball gets created, but perhaps there's a better way. The catch he

Re: Removing multiple copies of ltmain.sh

On Sat, 13 Jun 2009, Sam Varshavchik wrote: Can anyone suggest a clean way to eliminate all those copies of ltmain.sh. I can always hack up a hook that replaces them with hardlinks, before the tarball gets created, but perhaps there's a better way. The catch here is Libtool no longer u

Removing multiple copies of ltmain.sh

rious combinations. So when the major projects get packaged, the tarball gets multiple copies of ltmain.sh, one in each library subdirectory. Although gzip helps here, it's still quite a mouthful. Can anyone suggest a clean way to eliminate all those copies of ltmain.sh. I can always hack up a

reference to libgcc_s.so.1 without a corresponding run path (was: ltmain.sh (GNU libtool) 2.2)

Hi Bruce, * Bruce Korb wrote on Wed, Oct 01, 2008 at 04:11:41AM CEST: > cd ../getdefs ; gmake getdefs > gmake[4]: Entering directory > `/home/usr/bkorb/tools/ag/autogen-5.9.6pre15/_b/getdefs' > top_builddir=.. top_srcdir=../.. PATH=`cd ../columns >/dev/null && pwd`:$PATH > ; export top_builddir

Re: ltmain.sh (GNU libtool) 2.2

n-5.9.6pre15/_b/getdefs/getdefs] Error 2 $ ./libtool --version ltmain.sh (GNU libtool) 2.2 Written by Gordon Matzigkeit <[EMAIL PROTECTED]>, 1996 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even

ltmain.sh (GNU libtool) 2.2

make[4]: Leaving directory `/home/usr/bkorb/tools/ag/autogen-5.9.6pre15/_b/getdefs' gmake[3]: *** [/home/usr/bkorb/tools/ag/autogen-5.9.6pre15/_b/getdefs/getdefs] Error 2 $ ./libtool --version ltmain.sh (GNU libtool) 2.2 Written by Gordon Matzigkeit <[EMAIL PROTECTED]>, 1996 Copyr

Re: ltmain.sh (GNU libtool) 2.2

etdefs/getdefs] Error 2 $ ./libtool --version ltmain.sh (GNU libtool) 2.2 Written by Gordon Matzigkeit <[EMAIL PROTECTED]>, 1996 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCH

Re: libtoolize /ltmain.sh bug

Hallo Ralf! On 14 Feb 2008, at 06:11, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Mon, Feb 11, 2008 at 11:01:53PM CET: In an empty directory this happens: $ libtoolize --copy --ltdl touch: cannot touch `/ltmain.sh': Permission denied libtoolize: can not copy `/home/ralf/local/

Re: GCC with '-threads' on SOLARIS not supported by ltmain.sh

Hi Eric, * Eric PAIRE wrote on Thu, Jun 08, 2006 at 01:53:35PM CEST: > > I try to use libtool with a SOLARIS multithreaded library using SOLARIS > threads (not PTRHEADS) and gcc. It occurs that the option to use with > gcc '-threads' is not taken into account by l

Re: GCC with '-threads' on SOLARIS not supported by ltmain.sh

On Thu, 8 Jun 2006, Ralf Wildenhues wrote: I suggest that you read the threads(3THR) manual page for Solaris. It will become clear within the first paragraph. I promise! I read that, and it's not clear to me. Please be more explicit why we should not let '-threads' through. ;-) I think th

Re: GCC with '-threads' on SOLARIS not supported by ltmain.sh

On Thu, 8 Jun 2006, Eric PAIRE wrote: The threads(3THR) manual page for Solaris specifies: POSIX cc -mt [ flag... ] file...- lpthread [ -lposix4 library... ] Solaris cc - mt [ flag... ] file...[ library... ] But, if you read closely, you will see that the page refers to 'cc' and not 'g

Re: GCC with '-threads' on SOLARIS not supported by ltmain.sh

and if you read the specs files of 'gcc', you will discover that gcc refuses the '-mt' flag but accepts '-pthreads' flag when compiling for POSIX threads, and '-threads' one when compiling for SOLARIS threads, without having to add '-lpthread' (whic

Re: GCC with '-threads' on SOLARIS not supported by ltmain.sh

t; >'-threads' is not taken into account by ltmain.sh, whereas '-mt' (the one > >to be used with Sun CC) is. I read in the latest version (1.5.22) that the > >problem is still present. > > I suggest that you read the threads(3THR) manual page for Solaris.

Re: GCC with '-threads' on SOLARIS not supported by ltmain.sh

On Thu, 8 Jun 2006, Eric PAIRE wrote: I try to use libtool with a SOLARIS multithreaded library using SOLARIS threads (not PTRHEADS) and gcc. It occurs that the option to use with gcc '-threads' is not taken into account by ltmain.sh, whereas '-mt' (the one to be used wit

GCC with '-threads' on SOLARIS not supported by ltmain.sh

Hi, I try to use libtool with a SOLARIS multithreaded library using SOLARIS threads (not PTRHEADS) and gcc. It occurs that the option to use with gcc '-threads' is not taken into account by ltmain.sh, whereas '-mt' (the one to be used with Sun CC) is. I read in the lat

deplib find algorithm (was: Problem found: libtool/ltmain.sh pulling in wrong stdc++)

* Graham Leggett wrote on Fri, Aug 05, 2005 at 03:26:30PM CEST: > > I have found the reason for libtool linking to the wrong stdc++, the > problem is that I don't know libtool well enough to propose the "right" > solution. > - The variable "lib_search_path" contains the value below: > This varia

Problem found: libtool/ltmain.sh pulling in wrong stdc++

Hi all, I have found the reason for libtool linking to the wrong stdc++, the problem is that I don't know libtool well enough to propose the "right" solution. The problem plays out like this: - The stdc++ library is added to the "postdeps" environment variable, like this: postdeps="-lstdc++ -lm

Re: libtool/ltmain.sh pulling in wrong stdc++

On Wed, 2005-08-03 at 13:46 -0500, Bob Friesenhahn wrote: > On Wed, 3 Aug 2005, Ralf Corsepius wrote: > > > On Wed, 2005-08-03 at 13:57 +0200, Graham Leggett wrote: > >> Hi all, > > > >> What method needs to be used to tell libtool to link to stdc++ that > >> belongs to the compiler being run? > >

Re: libtool/ltmain.sh pulling in wrong stdc++

Christoph Bartoschek said: > I also have big problems that libtool tries to use /usr/lib/libstdc++ > instead of the compiler one, when I compile several projects. > > IMO libtool should always ignore libstdc++, but this is another issue. > > I solve the problem by patching libtool after configu

Re: libtool/ltmain.sh pulling in wrong stdc++

On Wed, 3 Aug 2005, Ralf Corsepius wrote: On Wed, 2005-08-03 at 13:57 +0200, Graham Leggett wrote: Hi all, What method needs to be used to tell libtool to link to stdc++ that belongs to the compiler being run? No method at all. libstdc++ is an internal library of g++ you are not supposed to

Re: libtool/ltmain.sh pulling in wrong stdc++

On Wed, Aug 03, 2005 at 07:30:39PM +0200, Graham Leggett wrote: > > The link line generated by libtool is: > > /bin/bash ../../libtool --tag=CC --mode=link gcc -I.. -I../.. > -I/usr/local/include/libxml2 -L/usr/local/lib -R/usr/local/lib -lxml2 -lz > -lpthread -liconv -lm -lsocket -lnsl -o libm

Re: libtool/ltmain.sh pulling in wrong stdc++

Christoph Bartoschek said: > I also have big problems that libtool tries to use /usr/lib/libstdc++ > instead of the compiler one, when I compile several projects. > > IMO libtool should always ignore libstdc++, but this is another issue. > > I solve the problem by patching libtool after configur

Re: libtool/ltmain.sh pulling in wrong stdc++

Christoph Bartoschek said: > I also have big problems that libtool tries to use /usr/lib/libstdc++ > instead of the compiler one, when I compile several projects. > > IMO libtool should always ignore libstdc++, but this is another issue. > > I solve the problem by patching libtool after configur

Re: libtool/ltmain.sh pulling in wrong stdc++

.18. > > I deleted config.guess, config.sub, libtool and ltmain.sh and recreated > them from scratch using libtoolize -c -f. > > The second project's libtool still somehow detects and pulls in the gcc > v3.4.2 libstdc++, while building with g++ v4.0.1. > > I am completely

Re: libtool/ltmain.sh pulling in wrong stdc++

Peter O'Gorman said: > It could be coming from an already installed .la file. I did a complete machine grep. The only references to libstdc++ within an .la file on this machine are in libstdc++.la itself, or in the .la files of the two projects. libstdc++ is not found in any other .la file on th

Re: libtool/ltmain.sh pulling in wrong stdc++

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Graham Leggett wrote: | I am completely baffled - can anyone reveal what method libtool uses to | detect libraries? What steps are followed to create the dependency_libs | variable within the .la file? I am trying to find out where the referencce | t

Re: libtool/ltmain.sh pulling in wrong stdc++

Kurt Roeckx said: > Are you sure your libtool has been regenerated for the new g++? I rebuilt libtool v1.5.8 which was previously installed, and when this made no difference I downloaded and built libtool v1.5.18. I deleted config.guess, config.sub, libtool and ltmain.sh and recreated them f

Re: libtool/ltmain.sh pulling in wrong stdc++

On Wed, Aug 03, 2005 at 01:57:20PM +0200, Graham Leggett wrote: > Hi all, > > I have been having a very strange problem that I have tracked down to > libtool, and I don't know how to proceed. > > I have a Solaris v2.8 machine with a system installed copy of gcc v3.4.2 > in /usr/local. Recently a

Re: libtool/ltmain.sh pulling in wrong stdc++

On Wed, 2005-08-03 at 13:57 +0200, Graham Leggett wrote: > Hi all, > What method needs to be used to tell libtool to link to stdc++ that > belongs to the compiler being run? No method at all. libstdc++ is an internal library of g++ you are not supposed to specify explicitly. The issue you describ

Re: libtool/ltmain.sh pulling in wrong stdc++

find any obvious difference between the libtool/autoconf setups in either project that would explain why one detects the correct gcc, while the other one does not. The script ltmain.sh seems to create the dependency_libs variable within the .la file. What script/program/command is used to create

libtool/ltmain.sh pulling in wrong stdc++

c and g++ are both in the path and take precedance: bash-2.03$ g++ --version g++ (GCC) 4.0.1 What method needs to be used to tell libtool to link to stdc++ that belongs to the compiler being run? How does ltmain.sh find libraries to create the dependancy_libs variable? Regards, G

Re: ltmain.sh

>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes: [...] Gary> I think that what we *really* need is for automake to not Gary> assume ltmain.sh is in the source tree, and some way for Gary> the libtool Makefile.am to declare that config/ltmain.sh Gary

ltmain.sh

Hi Alexandre! Having automake choke when ltmain.sh is missing causes no end of trouble for libtool... because obviously we don't have ltmain.sh yet at bootstrap time. We work around it by having a bootstrap script touch ltmain.sh before running automake, and then removing it so that

Re: ltmain.sh and configure

Hi Peter, On Wednesday, September 10, 2003, at 11:52 pm, Peter O'Gorman wrote: On Thursday, September 11, 2003, at 2:11 AM, Gary V. Vaughan wrote: Speak up if you are still interested Peter. Yes, I am still interested, thank you. Sorry time zone differences made a more prompt reply impossible,

Re: ltmain.sh and configure

Gary V. Vaughan wrote: Peter O'Gorman wrote: I assume you mean the libtool-1.5 is not available on gnu.org since it was hacked in March. I believe it's reappearance is waiting on a libtool admin letting the relevant folks know the md5 checksum for that release. The checksum I have is 0e1844f2

Re: ltmain.sh and configure

On Thursday, September 11, 2003, at 2:11 AM, Gary V. Vaughan wrote: Boehne, Robert wrote: While we're on the subject (sort of) Peter expressed some interest in becoming a co-maintainer. I think that is a good idea, what about you? Absolutely! My attention to the libtool lists has been intermitte

Re: ltmain.sh and configure

Hello. Bob Friesenhahn wrote: > > On Wed, 10 Sep 2003, Gary V. Vaughan wrote: [snip] > > I am interested :-) Rob rolled that release, and I don't have a tarball > > of 1.5 from which to generate the sum myself :-( What date did you > > download it? Hopefully, very soon after the upload judging

Re: ltmain.sh and configure

Bob Friesenhahn <[EMAIL PROTECTED]> writes: > I have a copy of libtool-1.5.tar.gz which was retrieved on April 15. > The MD5 checksum is also "0e1844f25e2ad74c3715b5776d017545". I have a copy dated April 14 with the same MD5 checksum. -- Russ Allbery ([EMAIL PROTECTED])

RE: ltmain.sh and configure

On Wed, 10 Sep 2003, Boehne, Robert wrote: > While we're on the subject (sort of) Peter expressed some interest in becoming > a co-maintainer. I think that is a good idea, what about you? That is something I would like to see as well. Bob == Bob Friesenhahn [

Re: ltmain.sh and configure

Hi Rob, Peter, Boehne, Robert wrote: While we're on the subject (sort of) Peter expressed some interest in becoming a co-maintainer. I think that is a good idea, what about you? Absolutely! My attention to the libtool lists has been intermittent to say the least while I am working on m4... and

RE: ltmain.sh and configure

Peter O'Gorman; Libtool Cc: [EMAIL PROTECTED] Subject: Re: ltmain.sh and configure Peter O'Gorman wrote: > I assume you mean the libtool-1.5 is not available on gnu.org since it > was hacked in March. I believe it's reappearance is waiting on a libtool > admin letting th

Re: ltmain.sh and configure

On Wed, 10 Sep 2003, Gary V. Vaughan wrote: > Peter O'Gorman wrote: > > I assume you mean the libtool-1.5 is not available on gnu.org since it > > was hacked in March. I believe it's reappearance is waiting on a libtool > > admin letting the relevant folks know the md5 checksum for that release. >

Re: ltmain.sh and configure

On Thursday, September 11, 2003, at 12:38 AM, Gary V. Vaughan wrote: The checksum I have is 0e1844f25e2ad74c3715b5776d017545 in case anyone is interested :) I am interested :-) Rob rolled that release, and I don't have a tarball of 1.5 from which to generate the sum myself :-( What date did yo

Re: ltmain.sh and configure

Peter O'Gorman wrote: I assume you mean the libtool-1.5 is not available on gnu.org since it was hacked in March. I believe it's reappearance is waiting on a libtool admin letting the relevant folks know the md5 checksum for that release. The checksum I have is 0e1844f25e2ad74c3715b5776d017545 i

Re: Réf. : Re: Réf. : Re: ltmain.sh and configure

e 'serial 47 AC_PROG_LIBTOOL', indicating that you have picked up the >> definition of AC_PROG_LIBTOOL (from the file libtool.m4) from libtool-1.5. >> >> ltmain.sh from 1.4.3 + libtool.m4 from 1.5 = broken ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Réf. : Re: Réf. : Re: ltmain.sh and configure

anks Max, Alain. "Max Bowsher" <[EMAIL PROTECTED]> le 09/09/2003 15:14:37 Pour :Alain BONNEFOY/Valence cc : [EMAIL PROTECTED] Objet : Re: Réf. : Re: ltmain.sh and configure [EMAIL PROTECTED] wrote: > Hi Max, > > Sorry for the mistake but in fact I invoke &quo

Re: Réf. : Re: ltmain.sh and configure

[EMAIL PROTECTED] wrote: > Hi Max, > > Sorry for the mistake but in fact I invoke "libtoolize -f -c' and > 'automake-1.7 -a -c '! > Anyway, I get a new ltmain.sh, the one is stored in my libtool (1.4.3) > directory. > So, either ltmain.sh is bad in libto

Re: ltmain.sh and configure

On Tuesday, September 9, 2003, at 8:41 PM, [EMAIL PROTECTED] wrote: That means I have a dependancy problem but I don't know what to update. I wanted to try libtool-1.5 but it that's a simple ghost!! I assume you mean the libtool-1.5 is not available on gnu.org since it was hacked in March. I bel

Réf. : Re: ltmain.sh and configure

Hi Max, Sorry for the mistake but in fact I invoke "libtoolize -f -c' and 'automake-1.7 -a -c '! Anyway, I get a new ltmain.sh, the one is stored in my libtool (1.4.3) directory. So, either ltmain.sh is bad in libtool-1.4.3 (I don't think so) or the source file which crea

Re: ltmain.sh and configure

${libname}${release}${shared_ext}$major $libname${shared_ext}' > > After some investigation and discussion with qnx peoples and the libiconv > developper, I found that libtool.m4 contains the following line: > >> 1085 4:shrext=".so" > > the original ltmain

ltmain.sh and configure

> 1085 4:shrext=".so" the original ltmain.sh (from libiconv-1.9.1, don't which libtool version) contains the following line 2756 eval shared_ext=\"$shrext\" Unfortunately, ltmain.sh from libtool-1.4.3 doesn't contain the same eval. So I define shrext

Re: max_cmd_len in ltmain.sh

ely set in the generated 'libtool' program that gets > installed on my machine, but I want to use 'libtoolize --force --copy' in > my package which dumps 'ltmain.sh' in the package directory; configure > builds libtool from that. But, the generated libtool is

Re: max_cmd_len in ltmain.sh

o use 'libtoolize --force --copy' in my package which dumps 'ltmain.sh' in the package directory; configure builds libtool from that. But, the generated libtool is then missing the definition of max_cmd_len. Am I missing

Re: max_cmd_len in ltmain.sh

On Sun, Jul 20, 2003 at 11:09:05AM -0700, Keith Packard wrote: > > I'm having trouble understanding how max_cmd_len is supposed to be getting > initialized in ltmain.sh so I can use libtoolize with my package. libtool > has a nice assignment, but ltmain.sh contains only r

max_cmd_len in ltmain.sh

I'm having trouble understanding how max_cmd_len is supposed to be getting initialized in ltmain.sh so I can use libtoolize with my package. libtool has a nice assignment, but ltmain.sh contains only references to this variable. Am I supposed to perform additional magic on the ltmain.sh

Re: autoreconf misses ltmain.sh

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 25 Sep 2002 12:03:42 +0200 > > Please, install! OK, done. I did find some errors in my proposed text (it didn't give the obvious workaround, and it credited the wrong people for the patch -- ouch!), so I installed the following patch instead.

Re: autoreconf misses ltmain.sh

| > I have not read all the details yet, but does anybody know what we | > must do to cope with Libtool 1.4.2? | | How about this patch to Autoconf? It should let us limp along until a | new libtool version is published. | | --- old/BUGS 2002-03-26 08:14:37.0 -0800 | +++ new/BUGS 200

Re: autoreconf misses ltmain.sh

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 24 Sep 2002 13:33:43 +0200 > > So as was kindly suggested by TED, we should have autoreconf work > around Libtool problems. I missed that suggestion somewhere in my mailbox (currently with 2035 messages to read, sigh); if you think it preferable

Re: autoreconf misses ltmain.sh

> "Roger" == Roger Leigh <[EMAIL PROTECTED]> writes: Ralf> .. still nobody wanting to care to fix it? >> AFAICT it's fixed in CVS Libtool. Roger> And in Debian. Am I crazy suggesting that Debian Libtool be the next Libtool release? ___ Libtool m

Re: autoreconf misses ltmain.sh

| Am Mon, 2002-09-23 um 10.49 schrieb Alexandre Duret-Lutz: | > >>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: | > | > [...] | > | > Ralf> http://mail.gnu.org/pipermail/libtool-patches/2002-January/001659.html | > | > Ralf> .. which seems to indicate that libtool is the culprit. |

Re: autoreconf misses ltmain.sh

Thomas Dickey wrote: > > > In my opinion it is prohibitive and stupid > > It's equally stupid to . I think everyone knows that autoreconf is not ready for prime time. >From someone who gets cranky when working code breaks because someone thought I shouldn't do things that way, let me s

Re: autoreconf misses ltmain.sh

On Mon, Sep 23, 2002 at 12:23:34PM +0200, Ralf Corsepius wrote: > In my opinion it is prohibitive and stupid not to have a libtool release > that can properly interact with autoconf. It's equally stupid to release a version of autoconf which cannot properly interact with released versions of li

Re: autoreconf misses ltmain.sh

Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: > >>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: > > [...] > > Ralf> http://mail.gnu.org/pipermail/libtool-patches/2002-January/001659.html > > Ralf> .. which seems to indicate that libtool is the culprit. > Ralf> => There doesn't e

Re: autoreconf misses ltmain.sh

Am Mon, 2002-09-23 um 10.49 schrieb Alexandre Duret-Lutz: > >>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: > > [...] > > Ralf> http://mail.gnu.org/pipermail/libtool-patches/2002-January/001659.html > > Ralf> .. which seems to indicate that libtool is the culprit. > Ralf> => There d

Re: autoreconf misses ltmain.sh

>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: [...] Ralf> http://mail.gnu.org/pipermail/libtool-patches/2002-January/001659.html Ralf> .. which seems to indicate that libtool is the culprit. Ralf> => There doesn't exist any officially released version of libtool that Ralf> is usa

Re: autoreconf misses ltmain.sh

Am Don, 2002-09-19 um 11.36 schrieb Alexandre Duret-Lutz: > >>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: > > Ralf> This bug has been present with previous versions of automake and > Ralf> autoconf (IIRC, it also has been reported several times before). > > I think this is the same

Re: autoreconf misses ltmain.sh

>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: Ralf> This bug has been present with previous versions of automake and Ralf> autoconf (IIRC, it also has been reported several times before). I think this is the same issue as http://mail.gnu.org/pipermail/libtool/2002-August/006640.h

autoreconf misses ltmain.sh

ing `./INSTALL' Makefile.am: required file `./NEWS' not found Makefile.am: required file `./README' not found Makefile.am: required file `./AUTHORS' not found Makefile.am: required file `./ChangeLog' not found Makefile.am: installing `./depcomp' configure.ac:9: required file `./

Re: Error in ltmain.sh

Also sprach Boehne, Robert: } Bill, } } If you can fix it in just a few lines, you don't need } a copyright assignment. } Hi Robert, Thanks. I'm going to have to retract my previous bug warning, though. It appears that a buggy version of ltmain.sh was distributed with the RPM package

Re: Error in ltmain.sh

Bill, If you can fix it in just a few lines, you don't need a copyright assignment. Robert -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: rboehne AT ricardo-us DOT com

Error in ltmain.sh

Hi all, There is an error in the libtool package which is still in the 1.4.2 version. The problem occurs around line 4356 of the ltmain.sh file: if test "$fast_install" = no && test -n "$relink_command"; then if test "$finali

libtool: ltconfig version `' does not match ltmain.sh version `1.3.5'

What could be causing this error with the Tomcat webapp build using libtool? libtool: ltconfig version `' does not match ltmain.sh version `1.3.5' ---> Full trace <--- [pb]ee110# make make[1]: Entering directory `/usr2/ecadtesting/webapp-module-1.0-tc40' make[1]: Entering

Re: ltmain.sh help please

#x27; >Building autoconf files for pbd ... >automake: configure.in: installing `./install-sh' >automake: configure.in: installing `./mkinstalldirs' >automake: configure.in: installing `./missing' >configure.in: 100: required file `./ltmain.sh' not found >Building

Re: ltmain.sh help please

"Gary V. Vaughan" wrote: > But is the file that the link points to missing or zero length? > > i.e.$ ls -l /usr/local/share/libtool/ltmain.sh > Sorry about that misread. Simple answer is no. --- ls -l /usr/local/share/libtool/ltmain.sh -rw-r--r--1 root

Re: ltmain.sh help please

On Wednesday 11 July 2001 10:39 am, Patrick Shirkey wrote: > "Gary V. Vaughan" wrote: > > Does the ltmain.sh link in your projecxt directory point to a missing or > > zero-length file? > > No. > > lrwxrwxrwx1 root root 34 Jul 10

Re: ltmain.sh help please

"Gary V. Vaughan" wrote: > > Does the ltmain.sh link in your projecxt directory point to a missing or > zero-length file? > No. lrwxrwxrwx1 root root 34 Jul 10 17:27 ltmain.sh -> /usr/local/share/libtool/ltmain.sh Does that

Re: ltmain.sh help please

Does the ltmain.sh link in your projecxt directory point to a missing or zero-length file? Cheers, Gary. On Tuesday 10 July 2001 9:27 am, Patrick Shirkey wrote: > I'm trying to install a program that relies on libtool and ltdl. It's > not going very well. > >

  1   2   >