Re: libtool problem

2018-06-27 Thread Alice Wonder
On 2018-06-27 09:44, Roumen Petrov wrote: Hello Alice, Alice Wonder wrote: Hello, [SNIP] Software (audacity) [SNIP] libtool: link: unable to infer tagged configuration libtool: link: specify a tag with `--tag' [SNIP] LIBTOOL=/opt/gnu/bin/libtool libtool is generated script . Generate

Re: libtool problem

2018-06-27 Thread Roumen Petrov
Hello Alice, Alice Wonder wrote: Hello, [SNIP] Software (audacity) [SNIP] libtool: link: unable to infer tagged configuration libtool: link: specify a tag with `--tag' [SNIP] LIBTOOL=/opt/gnu/bin/libtool libtool is generated script . Generated script has variable available_tags= and

Re: libtool problem

2018-06-26 Thread Alice Wonder
I think the problem must be with audacity. I tried building several other packages with the new gcc, including orc from the GStreamer project that requires libtool to build and I made sure (in mock buildroot) that only the /opt/gnu/bin/libtool I built was available - and they compiled, passed

Re: libtool problem

2018-06-26 Thread Robert Boehne
You are somehow mixing parts of libtool from different versions. --tag has been required since version 1.5, so some part of what you've built uses something even older, circa 2002. First, try re-generating the configury for this project using newish tools. 'autoreconf" might do it. You may also

Re: libtool problem with --whole-archive/--no-whole-archive

2015-02-16 Thread Venkatesh Vivekanandan
On 16 February 2015 at 14:38, Mike Frysinger wrote: > On 26 Nov 2014 11:20, Venkatesh Vivekanandan wrote: > > Problem is, platform linker command doesn't have > > --whole-archive/--no-whole-archive around the lib. Instead it comes later > > in the command line. > > iirc, libtool likes to sort thi

Re: libtool problem with --whole-archive/--no-whole-archive

2015-02-16 Thread Mike Frysinger
On 26 Nov 2014 11:20, Venkatesh Vivekanandan wrote: > Problem is, platform linker command doesn't have > --whole-archive/--no-whole-archive around the lib. Instead it comes later > in the command line. iirc, libtool likes to sort things for you > How to propogate the --whole-archive/--no-whole-ar

Re: libtool problem on system with 32 and 64 bit libraries

2009-05-12 Thread Bob Friesenhahn
On Tue, 12 May 2009, Markus Elfring wrote: It does not seem likely that anything as exotic as data structures and programming interfaces would be required. What is necessary is to get the right people interested. Would you like to introduce more software developers and designers into the topi

Re: libtool problem on system with 32 and 64 bit libraries

2009-05-12 Thread Markus Elfring
> It does not seem likely that anything as exotic as data structures and > programming interfaces would be required. What is necessary is to get > the right people interested. Would you like to introduce more software developers and designers into the topic for useful discussion of the details? W

Re: libtool problem on system with 32 and 64 bit libraries

2009-05-12 Thread Bob Friesenhahn
On Tue, 12 May 2009, Markus Elfring wrote: I am also interested to convert the wording from the specification into something where specific default settings can be processed automatically. http://pathname.com/fhs/pub/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL Will it be worth to invite mor

Re: libtool problem on system with 32 and 64 bit libraries

2009-05-12 Thread Markus Elfring
> My idea is to put this in one config file at a standard location which > can include site specific information. This could include information > such as special compile/link flags required for a particular > architecture format and expected subdirectory or library file naming. > It would list ar

Re: libtool problem on system with 32 and 64 bit libraries

2009-05-11 Thread Bob Friesenhahn
On Mon, 11 May 2009, Markus Elfring wrote: http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard The same sort of folks who were involved in developing this standard could help with an architecture rules specification format. Did you discuss this idea with any software developers befor

Re: libtool problem on system with 32 and 64 bit libraries

2009-05-11 Thread Markus Elfring
>> http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard > The same sort of folks who were involved in developing this standard > could help with an architecture rules specification format. Did you discuss this idea with any software developers before? > Up to now, I have not heard of any

Re: libtool problem on system with 32 and 64 bit libraries

2009-05-10 Thread Bob Friesenhahn
On Sun, 10 May 2009, Markus Elfring wrote: Can the file system hierarchy standard help here? http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard The same sort of folks who were involved in developing this standard could help with an architecture rules specification format. GNU does n

Re: libtool problem on system with 32 and 64 bit libraries

2009-05-09 Thread Markus Elfring
> It would be nice if there were standard file naming conventions. On > my Solaris 10 system, the operating system uses one convention and GCC > uses another. Packages may use another. Do you see chances for a mapping between the available approaches? Can the file system hierarchy standard hel

Re: libtool problem on system with 32 and 64 bit libraries

2009-05-09 Thread Bob Friesenhahn
On Sat, 9 May 2009, Markus Elfring wrote: Are there any chances to improve the situation on a limited combination of these software components? Yes, of course. Things become much easier if you only plan to solve a subset of the problem. But we should solve the whole problem. Can any defa

Re: libtool problem on system with 32 and 64 bit libraries

2009-05-09 Thread Markus Elfring
> If you know of a fully automatic way that works, and that not only for > your system your distribution your current version, but for strictly > more systems, distributions, versions, compilers and compiler versions > for which the current method works then we're all ears. Are there any chances

Re: libtool problem on system with 32 and 64 bit libraries

2009-05-09 Thread Bob Friesenhahn
On Sat, 9 May 2009, Ralf Wildenhues wrote: * Markus Elfring wrote on Fri, May 08, 2009 at 07:59:16PM CEST: I am curious if the libtool software will ever be able to determine the appropriate directory automatically on systems with multiple processor architectures. If you know of a fully autom

Re: libtool problem on system with 32 and 64 bit libraries

2009-05-09 Thread Ralf Wildenhues
Hello Markus, * Markus Elfring wrote on Fri, May 08, 2009 at 07:59:16PM CEST: > I am curious if the libtool software will ever be able to determine the > appropriate directory automatically on systems with multiple processor > architectures. If you know of a fully automatic way that works, and th

Re: libtool problem on system with 32 and 64 bit libraries

2009-05-08 Thread Markus Elfring
> Sorry that I was not of more help. It does seem necessary to specify > the linker path to 64-bit libraries on the system. The fixes in > libtool 2.2 seem to primarily be to assure that the correct compiler > support and system libraries are used. Libtool queries GCC for the > built-in linker s

Re: libtool problem on system with 32 and 64 bit libraries

2009-04-06 Thread Bob Friesenhahn
On Mon, 6 Apr 2009, Bernd Speiser wrote: After some more experimentation, I seem to have found the solution: I need to place `-L/usr/lib64 -L/usr/lib' in the LDFLAGS variable of the program to be built. Then, I get the expected behavior (libraries in /usr/lib do not interfere with those in /usr/

Re: libtool problem on system with 32 and 64 bit libraries

2009-04-06 Thread Bernd Speiser
After some more experimentation, I seem to have found the solution: I need to place `-L/usr/lib64 -L/usr/lib' in the LDFLAGS variable of the program to be built. Then, I get the expected behavior (libraries in /usr/lib do not interfere with those in /usr/lib64). Thanks for helping. Regards Bernd

Re: libtool problem on system with 32 and 64 bit libraries

2009-04-05 Thread Bernd Speiser
Bernd Speiser wrote: Bob Friesenhahn wrote: I expect that the problem is that a .la file loaded via the linking search path refers to this /usr/lib/libXfixes.la file which does not exist (because it was deleted or never was installed). The .la files are just ASCII text files that you can ope

Re: libtool problem on system with 32 and 64 bit libraries

2009-04-05 Thread Bob Friesenhahn
On Sun, 5 Apr 2009, Bernd Speiser wrote: thanks for this info. 1.5.26 is the default for openSUSE 11.0. However, I have installed libtool version 2.2.6 on my system now. With this, after regeneration of of the aclocal.m4 files, I still get an error message, although a different one: libtool: l

Re: libtool problem on system with 32 and 64 bit libraries

2009-04-05 Thread Bernd Speiser
Bob Friesenhahn wrote: On Fri, 3 Apr 2009, Bernd Speiser wrote: I am using autotools on openSUSE 11.0 x86_64 where I have a couple of libraries (notably the X libraries) installed as both 32 and 64 bit versions. I seem to have a problem which has been discussed several times on this list (lib

Re: libtool problem on system with 32 and 64 bit libraries

2009-04-03 Thread Bob Friesenhahn
On Fri, 3 Apr 2009, Bernd Speiser wrote: I am using autotools on openSUSE 11.0 x86_64 where I have a couple of libraries (notably the X libraries) installed as both 32 and 64 bit versions. I seem to have a problem which has been discussed several times on this list (libtool tries to link the 3

Re: libtool problem with library dependencies on ppc64

2008-11-11 Thread Peter O'Gorman
On 7-Nov-08, at 12:47 PM, Maynard Johnson wrote: Peter, I installed the same distro on a 32-bit Intel machine today and got the same problem. So my hunch that this was a 64bit-only problem was wrong. To restate the question . . . When only a libbfd.a is available for linking (i.e., no l

Re: libtool problem with library dependencies on ppc64

2008-11-07 Thread Maynard Johnson
Peter, I installed the same distro on a 32-bit Intel machine today and got the same problem. So my hunch that this was a 64bit-only problem was wrong. To restate the question . . . When only a libbfd.a is available for linking (i.e., no libbfd.so), should libtool be smart enough to figure out

Re: libtool problem with library dependencies on ppc64

2008-10-30 Thread Maynard Johnson
Maynard Johnson wrote: > Hello, Peter, > I've run into another problem with building the oprofile project that seems > like > it might be an issue with libtool. Recent versions of binutils have made > libbfd I forgot to mention that the libtool version being used in my situation is 2.2.6. T

Re: libtool problem when cross compiling net-snmp

2008-01-10 Thread Ralf Wildenhues
* Göran Hillebrink wrote on Thu, Jan 10, 2008 at 10:17:31AM CET: > > Attached are the logs you asked for. > libc is located in /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/lib. Thanks. So this is indeed the same issue as Mike Frysinger described in

RE: libtool problem when cross compiling net-snmp

2008-01-10 Thread Göran Hillebrink
: libtool@gnu.org Subject:Re: libtool problem when cross compiling net-snmp Hello Göran, * Göran Hillebrink wrote on Wed, Jan 09, 2008 at 04:27:27PM CET: > > I'm trying to cross compile net-snmp but have run into a libtool > problem. I'm using libtool 1.5.24 together

Re: libtool problem when cross compiling net-snmp

2008-01-09 Thread Ralf Wildenhues
Hello Göran, * Göran Hillebrink wrote on Wed, Jan 09, 2008 at 04:27:27PM CET: > > I'm trying to cross compile net-snmp but have run into a libtool > problem. I'm using libtool 1.5.24 together with net-snmp 5.4.1. > > I've tracked down the problem to archive_cmds in libtool. The $deplibs > parame

Re: libtool problem

2003-07-29 Thread M. Lavasani
> > > > > > > > I am trying to compile pango on HPUX-11.22 (IA64) platform using gcc-3.3.1. > > > > > > > > Pango first generates "libpango.so", Then it generates another library > > > > "libpangox.so" that links to "libpango.so". > > > > > > > > shared library list: > > > >

Re: libtool problem

2003-07-28 Thread Albert Chin
On Mon, Jul 28, 2003 at 08:45:00AM +0100, M. Lavasani wrote: > > > > > > > I am trying to compile pango on HPUX-11.22 (IA64) platform using gcc-3.3.1. > > > > > > Pango first generates "libpango.so", Then it generates another library > > > "libpangox.so" that links to "libpango.so". > > > > > >

Re: libtool problem

2003-07-28 Thread M. Lavasani
> > > > I am trying to compile pango on HPUX-11.22 (IA64) platform using gcc-3.3.1. > > > > Pango first generates "libpango.so", Then it generates another library > > "libpangox.so" that links to "libpango.so". > > > > shared library list: > > ./.libs/libpango.so > >

Re: libtool problem

2003-07-25 Thread Albert Chin
On Fri, Jul 25, 2003 at 10:27:58AM +0100, M. Lavasani wrote: > This is a general question, although I am going to refer to a > specific paltform and specific program. > > I am trying to compile pango on HPUX-11.22 (IA64) platform using gcc-3.3.1. > > Pango first generates "libpango.so", Then it