Compiling C++
Random files are generated wth .loT file type. Are there any known reasons for this behaviour? martin welsh ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling C++
On 06/07/15 23:18, Simon Richter wrote: Hi, On 06.07.2015 20:17, martin wrote: Random files are generated wth .loT file type. Files ending in T are temporary files that are generated because some compilers do not delete the output file on failure. These are renamed to the same name without the T at the end of the build step they belong to. If these remain somewhere, then something went wrong, for example an aborted build didn't clean them up. Files with the suffix .lo are generated by libtool, these are normal object files (.o), but compiled with the options necessary for shared libraries. The .loT files you see are thus remnants of a compiler invocation from libtool, and got left when a build was aborted or failed because the harddisk ran full. They can be safely deleted. Simon ___ https://lists.gnu.org/mailman/listinfo/libtool Thank you for your reply. I may be wrong but I think they may be occuring on clean builds. Let me give you the situation. The originator of the software programme, Horst Knorr is beleived to have died and I am trying to update hk_classes-0.8.3 from kde3+ to kde4. I am not a geek. The method of updating that I adopted was to configure and build the original file with kde4+ software. hk_classes comprises the drivers for various databases and the mechanics upon which the companion Kde programme may be built it is virtually all C++. When I compile it throws up errors and these errors are corrected, with a lot of help from Stack Overflow and a bit of common sense. Most 'repairs' are remembered and you finish up with a working programme for kde4 which is the display programme. If the cause is what you suggest how can you purge the input before compiling again? martin welsh ___ https://lists.gnu.org/mailman/listinfo/libtool
Mailing Lists
Please unsubscribe. ___ https://lists.gnu.org/mailman/listinfo/libtool
REQUEST: AC_PREFER_PIC macro
Hello, I'm currently using libtool 1.3c (feb 3 2000) and love the --prefer-pic feature. I'd really appreciate if there was a macro that could be used in our configure.in to specify that we'd prefer pic, or not, or both. (Just like the AC_ENABLE_?? AC_DISABLE_?? macros) Thanks! Martin -- __ Okiok Data ltd.| Spécialiste des solutions de sécurité d'entreprise Tel. : (450) 681.1681 | http://www.okiok.com | Specializing in enterprise security solutions
ltconfig decision in creating shared (c++) libraries on solaris.
Hello, In yout ltconfig script, there is the following comment concerning building shared libs on solaris: (this is taken at line 1335 of ltconfig, libtool version 1.3c 1.687, 2000/02/03) # $CC -shared without GNU ld will not create a library from C++ # object files and a static libstdc++, better avoid it by now This choice prevents me from compiling correctly with libtool on solaris. I have to build a c++ shared library that uses exception. Linking the shared library with libtool prevents exceptions from working correctly. In my experience, I do get correct results by manually using $(CC) -shared, at least with gcc 2.95.2. g++ calls collect2, which calls the linker. I only have the native linker installed on my machine. Here's a verbose transcript of what gcc 2.95.2 does when linking a shared lib. The setup is a c++ shared library that internally uses exceptions (libtest.so), with a c++ program using it (main). Begin Transcript 2 -- [mproulx@soleil solaris]$ uname -a SunOS soleil.okiok.com 5.6 Generic_105181-16 sun4m sparc SUNW,SPARCstation-5 [mproulx@soleil solaris]$ g++ -v --shared -o .libs/libtest.so test.lo Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/specs gcc version 2.95.2 19991024 (release) /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/collect2 -V -G -dy -z text -Y P,/usr/ccs/lib:/usr/lib -Qy -o .libs/libtest.so /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/crti.o /usr/ccs/lib/values-Xa.o /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/crtbegin.o -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2 -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/lib test.lo -lstdc++ -lm -lgcc -lgcc /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/crtend.o /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/crtn.o ld: Software Generation Utilities - Solaris/ELF (3.0) [mproulx@soleil solaris]$ ldd .libs/main ./.libs/libtest.so =>./.libs/libtest.so libm.so.1 => /usr/lib/libm.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 [mproulx@soleil solaris]$ ldd .libs/libtest.so libm.so.1 => /usr/lib/libm.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 End transcript 2 So maybe this requirement isn't a requirement anymore? Can anyone with the expertise clarify the situation, please? Thanks! Martin -- __ Okiok Data ltd.| Spécialiste des solutions de sécurité d'entreprise Tel. : (450) 681.1681 | http://www.okiok.com | Specializing in enterprise security solutions
Re: ltconfig decision in creating shared (c++) libraries on solaris.
Alexandre Oliva wrote: > > On Feb 15, 2000, Martin Proulx <[EMAIL PROTECTED]> wrote: > > > This choice prevents me from compiling correctly with libtool on > > solaris. > > > I have to build a c++ shared library that uses exception. > > Libtool doesn't support C++. This is just one of the problems you're > supposed to encounter. > I know the support isn't finished, but libtool does work fine with c++ on my linux box, and it might be partly because on that platform, the compiler is used to link. I believe that if libtool would use g++ to link c++ objects, its would have a lot more chances of working correctly than by directly using the native linkers. My point was simply that maybe if the GNU compilers on solaris are now able to do things correctly, that maybe libtool should trust the compiler and use it instead of directly using the native compiler because as I have said, using g++ to link c++ shared libs works correctly. Using only gcc (as libtool does) to link c++ libraries also works, but requires the additional linking with libstdc++. > C++ support is under development in the multi-language-branch of the > libtool CVS tree. Feel free to give it a try, and please report any > problems you find. > Ok, I'll give it a try. Thanks! Martin -- __ Okiok Data ltd.| Spécialiste des solutions de sécurité d'entreprise Tel. : (450) 681.1681 | http://www.okiok.com | Specializing in enterprise security solutions
Re: ltconfig decision in creating shared (c++) libraries on solaris.
Alexandre Oliva wrote:
>
> On Feb 15, 2000, Martin Proulx <[EMAIL PROTECTED]> wrote:
>
> C++ support is under development in the multi-language-branch of the
> libtool CVS tree. Feel free to give it a try, and please report any
> problems you find.
>
> --
> Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
> Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
> Free Software Developer and EvangelistCS PhD student at IC-Unicamp
> oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
I tried it, and I'm very happy that it does solve my c++ problem on
solaris.
The only glitch is that the c++ tag deplibs_check_method was set to
"unknown".
I manually modified it to "pass_all" (to match the C one, and I then had
a perfectly working libtool.
Thanks!
Martin
--
__
Okiok Data ltd.| Spécialiste des solutions de sécurité
d'entreprise
Tel. : (450) 681.1681 |
http://www.okiok.com | Specializing in enterprise security solutions
Re: ltconfig decision in creating shared (c++) libraries on solaris.
Ossama Othman wrote:
>
> Hi Martin,
>
>
> > The only glitch is that the c++ tag deplibs_check_method was set to
> > "unknown".
> >
> > I manually modified it to "pass_all" (to match the C one, and I then had
> > a perfectly working libtool.
>
> There are some other known glitches that I'm working on, but I wasn't
> aware of that one. Can you give me more details of your fix,
> specifically where did you make your fix?
>
> Thanks,
> -Ossama
> --
> Ossama Othman <[EMAIL PROTECTED]>
> Distributed Object Computing Laboratory, Univ. of California at Irvine
> 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
I simply manually edited the resulting libtool file. This isn't the
correct thing to do, but this will allow me to correctly build my c++
shared libs on solaris. I've attached the original, unmodified libtool
created after appending the CXX tag. In it, I've simply edited line 5337
to be like line 212.
It seems that the decision on how to set this variable is always taken
within aclocal's libtool.m4, according to the platform only.
The obvious problem is that the CXX tag's deplibs_check_methods
(and maybe other configurations) seem to end-up with default values,
rather than values derived from the C configurations, or derived from
their language's lt-cf???.sh script.
I've checked on a linux box as well, and it gets the same problem, so
you might be able to reproduce it. Generate a libtool, append a CXX
tag, and check that for the appended tag, at least deplibs_check_methods
is set to unknown.
If you want more details, feel free to ask.
Now I have a few questionsthat came to mind since I've started using the
multi-language libtool.
1-) Why do we have to respecify the able/disable static-shared flags
when appending a new tag? I wish the new language would simply use C's
defaults if not specified, rather than using the defaults which are to
generate both shared and static libs. Is this meant to be, or is this
related to the above problem I encountered?
2-) If libtool will indeed be able to generate different mixed
static/shared configurations for every language. How will the
automake/autoconf integration will
work. Will there be "--enable-LANG-shared" and so on flags to
autoconf? Will there be AC_ENABLE_LANG_SHARED macros to be used in
autoconf.in ?
3-) Will the AC_PROG_LIBTOOL macro be intelligent enough to discover all
the languages used in the project, and create automatically a libtool
that supports all these languages?
Thanks!
Martin
--
__
Okiok Data ltd.| Spécialiste des solutions de sécurité
d'entreprise
Tel. : (450) 681.1681 |
http://www.okiok.com | Specializing in enterprise security solutions
#! /bin/sh
# libtool - Provide generalized library-building support services.
# Generated automatically by ltconfig (GNU libtool 1.3c (1.641.2.17 2000/02/08
18:47:29))
# NOTE: Changes made to this file will be lost: look at ltconfig or ltmain.sh.
#
# Copyright (C) 1996-2000 Free Software Foundation, Inc.
# Originally by Gordon Matzigkeit <[EMAIL PROTECTED]>, 1996
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
#
# As a special exception to the GNU General Public License, if you
# distribute this file as part of a program that contains a
# configuration script generated by Autoconf, you may include it under
# the same distribution terms that you use for the rest of that program.
# Sed that helps us avoid accidentally triggering echo(1) options like -n.
Xsed="sed -e s/^X//"
# The HP-UX ksh and POSIX shell print the target directory to stdout
# if CDPATH is set.
if test "X${CDPATH+set}" = Xset; then CDPATH=:; export CDPATH; fi
# The names of the tagged configurations supported by this script.
available_tags="available_tags= CXX"
### BEGIN LIBTOOL CONFIG
# Libtool was configured as follows, on host soleil.okiok.com:
#
# LTCC="gcc" CC="gcc" CFLAGS="-g -O2" CPPFLAGS="" \
# LD="/usr/ccs/bin/ld" LDFLAGS="" LIBS="" \
# NM="/usr/local/bin/nm -B" RANLIB=
Re: ltconfig decision in creating shared (c++) libraries on solaris.
Ossama Othman wrote: > > Hi Martin, > > > BTW, are you using the AC_LIBTOOL_CXX macro, or are you appending > manually? It looks like you're appending manually. I bet that's why > the deplibs_check_method wasn't set properly for you. Sorry, I didn't > document AC_LIBTOOL_CXX yet. > You're right, I wasn't using this macro. I was simply calling ltconfig with --add-tag. I've retried with the AC_LIBTOOL_CXX macro, and the CXX tag is correctly generated in this case. :) The only problem I encountered using this macro is that libtoolize failed to detect the macro and automatically copy the ltcf-cxx.sh file in my source tree. > > 2-) If libtool will indeed be able to generate different mixed > > static/shared configurations for every language. How will the > > automake/autoconf integration will > > work. Will there be "--enable-LANG-shared" and so on flags to > > autoconf? Will there be AC_ENABLE_LANG_SHARED macros to be used in > > autoconf.in ? > > I haven't thought this far ahead. :-) > I just wanted to get multi-language support working, and then tweak > stuff afterwards. > > > 3-) Will the AC_PROG_LIBTOOL macro be intelligent enough to discover all > > the languages used in the project, and create automatically a libtool > > that supports all these languages? > > Wow, good question. This is again something I didn't think about but > it seems like it might be useful. I won't have to look at > implementing such a feature for a while, however. Does anyone have > any thoughts on this? Now that I'm aware of the AC_LIBTOOL_CXX macro, all my questions are answered! My second question arose because when I manually appended the tag using ltconfig.sh, I had to respecify the linking modes. Using AC_LIBTOOL_CXX, this doesn't have to be done, as they're correctly inherited from C. I never had a project where I wished to link differently in C and C++. My third question's answer is obvious: Using AC_LIBTOOL_CXX, we can explicitely specify that we need c++ support from libtool. So to resume my situation, apart from having to manually copy ltcf-cxx.sh into my source tree, libtool multi-languages is so far working for me (including library dependencies) on: Sparc Solaris 2.6, gnu c/c++ compiler (2.95.2), native ld i386 Linux 2.2.12 (RedHat 6.1), gnu c/c++ compiler (2.95.2), GNU ld (2.9.5) Would it be useful to you if I ran the tests suite and sent you the results for these 2 platforms or do you already have access to these platforms? I will also have to test it within a few weeks on some NCR unix machine, with (hopefully) gnu compilers. I'll keep you informed then! Thanks for supporting me even with development releases! Martin -- __ Okiok Data ltd.| Spécialiste des solutions de sécurité d'entreprise Tel. : (450) 681.1681 | http://www.okiok.com | Specializing in enterprise security solutions
libtool-ml c++ and require_version support for sysv4.3-ncr
Hello, I've used the multi-language development branch of libtool lately, and appreciated it greatly. I recently had to compile one of our programs on an i586-ncr-sysv4.3.03 machine. I then realized that the c++ support hadn't been added for this plaform. I was still able to have libtool work as I wished by manually editing it to change the "require_version" to no, and by setting the archive_cmds and archive_expsyms_cmds and others for CXX to what they were for the C language. I used version 1.641.2.17 (2000/02/08) of libtool-ml, and the g++ compiler, version 2.95.2. I believe all the GNU binutils were installed on this machine. I would like to help add the correct support for this platform for libtool-ml. My question is, do you have any sort of test suite that I could run on the machine that would let us know what are the correct configurations for "require_version" and the c++ configurations, for at least the GNU compiler? Thanks! Martin -- __ Okiok Data ltd.| Spécialiste des solutions de sécurité d'entreprise Tel. : (450) 681.1681 | http://www.okiok.com | Specializing in enterprise security solutions
Re: mail archives are hosed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii "Gary V. Vaughan" writes: | I'm Ccing the administrators list at gnu.org, to highlight the fact | that the old archives are not available from either the old or new web | address =(O| I'm working on importing all of the historical GNU mailing list archives into the Mailman pipermail archiver. Hopefully we'll be there later this week. I'd like to make FTP access to the archives fall out in the wash, but this needs to be setup carefully so as to only make public mailing list archives visible. May take a little longer, unless someone beats me to it... -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 + martin iD8DBQE541P3Vw+hz3xBJfQRAlxKAJ90Qc/EKCcCZ9SCzudovA1ZRZSzkwCfa59e N52cSGUn0HA3dMNfTTG0vD0= =J8Gz -END PGP SIGNATURE- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Removing duplicate occurences from dependency_libs
Hi, somewhere between libtool 1.3.x and 1.4, you did the following: 1999-12-15 Thomas Tanner <[EMAIL PROTECTED]> * ltmain.in: don't remove multiple occurences from dependency_libs of a library, otherwise many dependencies would get lost If you have a "complicated" dependency setup, this will slow down linking in a very extreme way (it is more than 5 times slower for me) because I get libraries like -lm or -ldl listed over 30 times in the dependency_libs. Is it possible to add an argument to libtool to get back the old behavior, for instance -unique-dependency-libs ? Here's a patch for this: diff -- Martin Baulig [EMAIL PROTECTED] (private) [EMAIL PROTECTED] (work)
Re: Removing duplicate occurences from dependency_libs
Alexandre Oliva <[EMAIL PROTECTED]> writes: > On May 20, 2001, Martin Baulig <[EMAIL PROTECTED]> wrote: > > > If you have a "complicated" dependency setup, this will slow down linking > > in a very extreme way (it is more than 5 times slower for me) because I get > > libraries like -lm or -ldl listed over 30 times in the dependency_libs. > > > Is it possible to add an argument to libtool to get back the old behavior, > > for instance -unique-dependency-libs ? > > Just make sure no library appears explicitly more than once in the > dependence list of any library or program, and you'll get exactly what > you want. This does not work. Imagine the following scenario: liba.la - depends on -lm libb.la - depends on -lm libc.la - depends on -la and -lb You'll get -l twice in libc.la. -- Martin Baulig [EMAIL PROTECTED] (private) [EMAIL PROTECTED] (work) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Removing duplicate occurences from dependency_libs
Alexandre Oliva <[EMAIL PROTECTED]> writes: > That's why I wrote *explicitly*. You shouldn't get -lm duplicated in > this case. If you do, it's a bug. You should only get it duplicated > if it appeared more than once in the dependence list of liba.la or > libb.la; if it appears only once it both of them, only the last one > should prevail. Well, that's what didn't work for me. I'll debug it later on. -- Martin Baulig [EMAIL PROTECTED] (private) [EMAIL PROTECTED] (work) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Auto-tools & Win32 & Borland C++ Builder
> Before I address your points, or at least the ones I plan to address, > I thought first I would write my own critique of the auto tools. > While I do think that these tools have deep problems, I also think you > largely avoided mentioning them. Yes, you're right, I avoided that. if you're looking into such an environment there are many aspects you have to think about. Maybe we should do a discussion for what aspects of software development the autotools can be used for and what is missing for being are real development platform. > The most visible problem with these tools is complexity. In part this > complexity is justified; configuration and building is by nature > complex. However, some of this complexity occurs for reasons having > to do with design and implementation choices; that is, features of the > solution and not the problem. Yes I agree, the complexity of the autotools is really big. This was the reason for asking for deeper documentation for these tools. Right now you get the most if you're looking into the source. This is a little difficult, because you have to know something about m4, make and sh syntax and because there are many tools this all is not much readable. > For one thing, the reliance on very few Unix tools is crippling. > Portable sh is very limited indeed, and adds greatly to the amount of > knowledge and the time required to write a portable configuration > environment. Worse, this cost is distributed not only throughout the > tools themselves, but to the users of the tools. Likewise, reliance > on the portable subset of `make' means that automake, and its input > language, are quite constrained. Yes. > On top of the deficiencies of sh and make is the fact that you also > get to deal with m4. So now there are 3 quoting discipline: sh, m4, > and make, and you get to mix and match them. There are more problems > along these lines which I won't go into. I'm sure anybody familiar > with the tools has run into them. Yes. > Another contributing factor to the complexity is rooted in the > historical design of the tools. They were not designed as a whole, > but were instead designed and built in pieces, by different people. > Nobody who set out to design a configuration/build system would come > up with the auto tools. It is a bizarre solution, driven by > particular historical, technical, and political needs. > I think I can also come up with a coherent picture of what a nice > design would look like. In my plan, we avoid make and sh and m4 > entirely. We have a single tool that integrates configuration and the > build. This is quite a change, but the result, IMNSHO, looks quite > pretty: a package expresses its dependencies, not only in terms of how > it is to be built, but also in terms of what configuration information > it needs. Changes to the configuration or build environment result in > minimal re-configury. Etc; I could go on in great detail about the > idea but I won't right now. Sounds good, maybe we should search a better place to discuss these. > On to your complaints. > Martin> I think the great misunderstanding is that the autotools are > Martin> not targeting real multiplatform development, but Unix centric > Martin> distribution of (GNU) OpenSource Software. > Often times people seem to get annoyed that these tools don't do what > they expect. This is usually a bug in that person's expectations. That's sooo true. > Historically these tools were Unix-only. In the recent past there has > been some attempt to include Windows (particularly via Cygwin; I've > had a lot of success with that). I don't think people pretend > otherwise. I think this is one of the most urgent problems, it's Unix centric. We have with cygwin a Unix environment on Windows, but that not the whole truth. Since Windows have a great developer community with other development environment than Unix the autotools aren't really multiplatform. And I think at the moment the autotools don't want/can to support native non Unix platforms. > Martin> * changing a autotool file, then waiting for configure to > Martin> write 1200 makefiles. > Yes, that's a problem. In fact build times in general are a problem. > Some of this is due to the auto* model. Some of it is due to the > inherent lameness of make. There are two different models possible (plus a mixture of them) 1. to do all the configuration at configure time 2. or let the developer decide at developement time what he really want. That means that you're only do some base configuration at configure time and control with the help of variables the rest later. > Martin> * Mixing up debug and non debug build, do both causes double > Martin>
Re: libtool doesn't allow "make DESTDIR=`pwd`/foo install" anymore.
tis 2001-11-27 klockan 15.54 skrev Rob Browning: > If you build a package with --prefix=/usr and that package has > interdependencies among it's shared libraries (like guile and > heimdal), libtool will no longer allow you to install to a temporary > directory via > > make DESTDIR=`pwd`/foo install > > libtool 1.4 allowed this, but as of at least 1.4.2, it doesn't. This > makes it very difficult, if not impossible to package programs using > libtool for systems like debian that require creating a local install > from which the package is generated. We have this problem with our package ogle as well. Libtool 1.4 allowed this, but didn't do it correctly. I haven't tried libtool 1.4.2 yet. See my mail to this list: http://mail.gnu.org/pipermail/libtool/2001-October/005646.html > See http://bugs.debian.org/libtool, bugs 57087 and 98342. This seems to be the problem we have too. > I also wanted to see if anyone had suggestions for a fix, even a > temporary one. There's a patch in the debian package that seems to > fix the problem for some people, but still doesn't work for other > package like guile and heimdal. No, I have not found a solution to this problem. Our current approach when building RPMS is to build the package twice, the second time with the package partially installed. Not very good. Regards, Martin -- [ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ] Opinions expressed above are mine, and not those of my future employees. SIGBORE: Signature boring error, core dumped ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool doesn't allow "make DESTDIR=`pwd`/foo install" anymore.
tis 2001-11-27 klockan 17.38 skrev Paul E Johnson:
> This libtool issue is a known and fixed problem in libtool cvs. I built
> rpms of that snapshot of libtool and I've tested it and it does work.
> If you want to try the RPMS, I stashed them in here
> http://lark.cc.ukans.edu/~pauljohn/software
I tried rebuilding the ogle RPM with your new version of libtool
(libtool-20011121-1pj), and got the errors shown in the attached file.
There are still things like
libtool: install: warning: `../ogle/libmsgevents.la' has not been
installed in `/usr/lib/ogle'
Regards,
Martin
--
[ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN:
4439498 ]
Opinions expressed above are mine, and not those of my future
employees.
SIGBORE: Signature boring error, core dumped
Installerar ogle-0.8.1-1.src.rpm
Kör(%prep): /bin/sh -e /var/tmp/rpm-tmp.33843
+ umask 022
+ cd /home/martin/rpm/BUILD
+ cd /home/martin/rpm/BUILD
+ rm -rf ogle-0.8.1
+ /bin/gzip -dc /home/martin/rpm/SOURCES/ogle-0.8.1.tar.gz
+ tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd ogle-0.8.1
++ /usr/bin/id -u
+ '[' 502 = 0 ']'
++ /usr/bin/id -u
+ '[' 502 = 0 ']'
+ /bin/chmod -Rf a+rX,g-w,o-w .
+ exit 0
Kör(%build): /bin/sh -e /var/tmp/rpm-tmp.78237
+ umask 022
+ cd /home/martin/rpm/BUILD
+ cd ogle-0.8.1
+ CFLAGS=-O2 -march=i386 -mcpu=i686
+ export CFLAGS
+ CXXFLAGS=-O2 -march=i386 -mcpu=i686
+ export CXXFLAGS
+ FFLAGS=-O2 -march=i386 -mcpu=i686
+ export FFLAGS
+ '[' -f configure.in ']'
+ libtoolize --copy --force
You should update your `aclocal.m4' by running aclocal.
+ ./configure i386-redhat-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin
+--sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include
+--libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var
+--sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking whether to enable maintainer-specific portions of Makefiles... no
checking host system type... i386-redhat-linux-gnu
checking for gcc... gcc
checking whether the C compiler (gcc -O2 -march=i386 -mcpu=i686 ) works... yes
checking whether the C compiler (gcc -O2 -march=i386 -mcpu=i686 ) is a
cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for Cygwin environment... no
checking for mingw32 environment... no
checking how to run the C preprocessor... gcc -E
checking build system type... i386-redhat-linux-gnu
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependant libraries... pass_all
checking for object suffix... o
checking for executable suffix... no
checking command to parse /usr/bin/nm -B output... ok
checking for dlfcn.h... yes
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo...
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking whether the linker (/usr/bin/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking if libtool supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
creating libtool
checking whether byte ordering is bigendian... no
checking for working const... yes
checking for inline... inline
checking for byteswap.h... yes
checking for sys/bswap.h... no
checking for sys/endian.h... no
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for dnet_ntoa in -ldnet... no
checking for dnet_ntoa in -ldnet_stub... no
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for X11/extensions/XShm.h... yes
checking for XShmQueryExtension in -lXext... yes
checking for X11/extensions/Xv.h... yes
checking for XvQueryExtension in -lXv... yes
checking for main in -ljpeg... yes
checking for jpeglib.h... yes
checking for clock_gettime... no
checking for clock_gettime in -l
Re: libtool doesn't allow "make DESTDIR=`pwd`/foo install" anymore.
2001-11-27 13:11:09-0600, Paul E Johnson <[EMAIL PROTECTED]> -> > Obviously, I can't invest the time to bugshoot all these applications > that won't compile, about which I have been emailed by many people in > this list during the past 2 hours. Well I don't expect you too do that, I just wanted to inform that just upgrading to the latest libtool didn't solve my problem. > I can add this information, however. > > I achieved this success with the newer automake and autoconf, > $ rpm -q automake > automake-1.5-1pj > [pauljohn@valinux fs]$ rpm -q autoconf > autoconf-2.52-1pj Ok. Now I have: automake-1.5-1 autoconf-2.52-4 (both from redhat rawhide). After changing my configure.in to conform with the new autoconf, I tried to rebuild the source, package it and build the RPM. Still the same error. I really hope some libtool person can shed a light on this. Regards, Martin -- [ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ] Opinions expressed above are mine, and not those of my future employees. SIGBORE: Signature boring error, core dumped ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool 1.4, rpm, and dynamic libraries depending on each other
I don't know where to ask this, but this is as good a place as any I guess (rpm-list and libtool-list). My problem is this: I have two dynamic libraries in the project. One of them depends on the other, so I have pkglib_LTLIBRARIES = libmsgevents.la libdvdcontrol.la libmsgevents_la_LDFLAGS = -version-info 3:0:0 libdvdcontrol_la_LIBADD = libmsgevents.la libdvdcontrol_la_LDFLAGS = -version-info 3:0:0 among other things in my Makefile.am. As you can see, libdvdcontrol depends on libmsgevents. This works well when installing normally. However, when building an RPM package RPM installs the package in a directory different from the directory in which the package should be installed. This is so that non-root users can build the rpm packages. This makes libtool not find libmsgevents in the intended installation location, because it's not there. Is there a way around this? Any fix or workaround is fine. The very clumsy workaround I use right now is, build the rpm package. Install with --nodeps, build the package _again_ (this time libtool finds libmsgevents since it's installed), remove the old package, install the new package. Oh, and if you want the full source code and the source rpms, please find them at http://www.dtek.chalmers.se/~dvd/ Regards, Martin -- [ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ] Opinions expressed above are mine, and not those of my future employees. SIGBORE: Signature boring error, core dumped ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Hack for inter-library dependency (make DESTDIR=... install) problem.
2001-12-07 10:58:23-0600, Rob Browning <[EMAIL PROTECTED]> -> > Rob Browning <[EMAIL PROTECTED]> writes: > > > Agreed -- the same is true with Debian -- minimizing the Debian diff > > is a good idea, all other things being equal. In any case, thanks > > so much. I'll try this -- it looks like a good solution. > > That appeared to work perfectly -- thanks again. Worked for me too when building RPMS! Regards, Martin -- [ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ] Opinions expressed above are mine, and not those of my future employees. SIGBORE: Signature boring error, core dumped ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Hack for inter-library dependency (make DESTDIR=... install) problem.
2001-12-07 14:58:14-0800, [EMAIL PROTECTED] ->
> ==> "mn" == Martin Norbäck <[EMAIL PROTECTED]> writes:
>
> >> > Agreed -- the same is true with Debian -- minimizing the
> >> Debian diff > is a good idea, all other things being equal. In
> >> any case, thanks > so much. I'll try this -- it looks like a
> >> good solution.
> >>
> >> That appeared to work perfectly -- thanks again.
>
> mn> Worked for me too when building RPMS!
>
> I didn't realize it was that popular. In that case, here is the shell
> script I'm using. It's not easy to stick helper scripts into spec
> files, so you'll probably need to put it in as a Source: file and
> refer to it using $RPM_SOURCE_DIR:
[...]
Actually, all I had to do in my spec file was to add:
LIBRARY_PATH=%{buildroot}/usr/lib/ogle
export LIBRARY_PATH
before
make DESTDIR=%{buildroot} install
Regards,
Martin
--
[ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ]
Opinions expressed above are mine, and not those of my future employees.
SIGBORE: Signature boring error, core dumped
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
HELP: libtool not compiling on Solaris 10u10 T5120
Hello, I am trying to compile libtool so I can install another package which requires it. I have successfully compiled M4, Automake, Autoconf and installed in /usr/gnu. When I try to do the same for libtool, I receive errors. I have tried the following: ./configure --prefix=/usr/gnu /usr/css/bin/make Receive error: libtool: Version mismatch error. This is libtool 2.4.2, revision 1.3337, libtool: but the definition of this LT_INIT comes from revision 1.3201. libtool: You should recreate aclocal.m4 with macros from revision 1.3337 libtool: of libtool 2.4.2 and run autoconf again. *** Error code 63 make: Fatal error: Command failed for target `libltdl/loaders/libltdl_libltdl_la-preopen.lo' Current working directory /root/nicstat-1.90/ntop/ntop-5.0.1/libtool/libtool-2.4.2 *** Error code 1 The following command caused the error: fail= failcom='exit 1'; \ for f in x $MAKEFLAGS; do \ case $f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ So I then tried from that same build directory, # /usr/gnu/bin/autoreconf --force --install and that errors out with: Can't exec "libtoolize": No such file or directory at /usr/gnu/share/autoconf/Autom4te/FileUtils.pm line 345, line 6. autoreconf: failed to run libtoolize: No such file or directory autoreconf: libtoolize is needed because this package uses Libtool Here are my settings: Generic_147440-15 sun4v sparc SUNW,SPARC-Enterprise-T5120 echo $PATH /usr/gnu/bin:/usr/gnu:/usr/ccs/bin:/usr/sbin:/usr/bin:/opt/EMCpower/bin:/etc/emc/bin:/etc:/usr/openv/netbackup/bin:/usr/openv/netbackup/bin/admincmd:/usr/openv/volmgr/bin:/opt/Navisphere/bin:/opt/ELXocm:/opt/Navisphere/bin:/opt/pbis/bin:/usr/sfw/bin echo $LD_LIBRARY_PATH /etc/emc/rsa/cst/lib Summary of my perl5 (revision 5 version 8 subversion 4) configuration: Platform: osname=solaris, osvers=2.10, archname=sun4-solaris-64int uname='sunos localhost 5.10 sun4u sparc SUNW,Ultra-2' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Any advice is appreciated, TIA. --Jeff___ https://lists.gnu.org/mailman/listinfo/libtool
HELP: libtool 2.4.2 not compiling on Solaris 10u10 Sparc
Hello, I am trying to compile libtool so I can install another package which requires it. I have successfully compiled M4, Automake, Autoconf and installed in /usr/gnu. When I try to do the same for libtool, I receive errors. I have tried the following: ./configure --prefix=/usr/gnu /usr/css/bin/make Receive error: libtool: Version mismatch error. This is libtool 2.4.2, revision 1.3337, libtool: but the definition of this LT_INIT comes from revision 1.3201. libtool: You should recreate aclocal.m4 with macros from revision 1.3337 libtool: of libtool 2.4.2 and run autoconf again. *** Error code 63 make: Fatal error: Command failed for target `libltdl/loaders/libltdl_libltdl_la-preopen.lo' Current working directory /root/nicstat-1.90/ntop/ntop-5.0.1/libtool/libtool-2.4.2 *** Error code 1 The following command caused the error: fail= failcom='exit 1'; \ for f in x $MAKEFLAGS; do \ case $f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ So I then tried from that same build directory, # /usr/gnu/bin/autoreconf --force --install and that errors out with: Can't exec "libtoolize": No such file or directory at /usr/gnu/share/autoconf/Autom4te/FileUtils.pm line 345, line 6. autoreconf: failed to run libtoolize: No such file or directory autoreconf: libtoolize is needed because this package uses Libtool Here are my settings: Generic_147440-15 sun4v sparc SUNW,SPARC-Enterprise-T5120 echo $PATH /usr/gnu/bin:/usr/gnu:/usr/ccs/bin:/usr/sbin:/usr/bin:/opt/EMCpower/bin:/etc/emc/bin:/etc:/usr/openv/netbackup/bin:/usr/openv/netbackup/bin/admincmd:/usr/openv/volmgr/bin:/opt/Navisphere/bin:/opt/ELXocm:/opt/Navisphere/bin:/opt/pbis/bin:/usr/sfw/bin echo $LD_LIBRARY_PATH /etc/emc/rsa/cst/lib Summary of my perl5 (revision 5 version 8 subversion 4) configuration: Platform: osname=solaris, osvers=2.10, archname=sun4-solaris-64int uname='sunos localhost 5.10 sun4u sparc SUNW,Ultra-2' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Any advice is appreciated, TIA. --Jeff ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: HELP: libtool 2.4.2 not compiling on Solaris 10u10 Sparc
Bob, Yes it was pulled from gnu.org. -rw-r--r-- 1 root root 2632347 Oct 18 2011 libtool-2.4.2.tar.gz I used: wget http://www.mirrorservice.org/sites/ftp.gnu.org/gnu/libtool/libtool-2.4.2.tar.gz to retrieve the source. Thanks, Jeff - Original Message - From: Bob Friesenhahn To: Jeff Martin Cc: "libtool@gnu.org" Sent: Sunday, August 19, 2012 10:59 AM Subject: Re: HELP: libtool 2.4.2 not compiling on Solaris 10u10 Sparc On Sun, 19 Aug 2012, Jeff Martin wrote: > Hello, > I am trying to > compile libtool so I can install another package which requires it. I > have successfully compiled M4, Automake, Autoconf and installed in > /usr/gnu. > When I try to do the same for libtool, I receive errors. > I have tried the following: I can't tell where you obtained this libtool from. Are you using the official libtool source package from ftp://ftp.gnu.org/pub/gnu/libtool or are you using something you happened to find bundled (and quite possibly botched) in some other package's tarball? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: HELP: libtool 2.4.2 not compiling on Solaris 10u10 Sparc
Update. Really not sure why, but I started a new session and now the compile is working. So perhaps it was something with my session. I'll probably never know exactly but I am just glad its working now. Thanks, jeff - Original Message - From: Bob Friesenhahn To: Jeff Martin Cc: "libtool@gnu.org" Sent: Sunday, August 19, 2012 10:59 AM Subject: Re: HELP: libtool 2.4.2 not compiling on Solaris 10u10 Sparc On Sun, 19 Aug 2012, Jeff Martin wrote: > Hello, > I am trying to > compile libtool so I can install another package which requires it. I > have successfully compiled M4, Automake, Autoconf and installed in > /usr/gnu. > When I try to do the same for libtool, I receive errors. > I have tried the following: I can't tell where you obtained this libtool from. Are you using the official libtool source package from ftp://ftp.gnu.org/pub/gnu/libtool or are you using something you happened to find bundled (and quite possibly botched) in some other package's tarball? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
checking command to parse /usr/bin/nm -B output from gcc object... failed
Hello. nm -B detection fails to be detected with -flto and -fno-common CFLAGS: configure:6307: checking command to parse /usr/bin/nm -B output from gcc object configure:6460: gcc -c -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -fno-common -flto conftest.c >&5 configure:6463: $? = 0 configure:6467: /usr/bin/nm -B conftest.o \| sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' \> conftest.nm configure:6470: $? = 0 configure:6536: gcc -o conftest -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -fno-common -flto -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -fno-common -flto conftest.c conftstm.o >&5 conftest.c:18:12: error: variable 'nm_test_var' redeclared as function 18 | extern int nm_test_var(); |^ conftest.c:4:6: note: previously declared here 4 |relocations are performed -- see ld's documentation on pseudo-relocs. */ | ^ lto1: fatal error: errors during merging of translation units compilation terminated. lto-wrapper: fatal error: gcc returned 1 exit status compilation terminated. /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status configure:6539: $? = 1 As seen, I bet problem is in conftstm.o file (for which I can't see how it's created). Probably the file is missing declaration of nm_test_var and so that it's implicitly deduced to be int nm_test_var(). Thanks, Martin
Re: checking command to parse /usr/bin/nm -B output from gcc object... failed
On 1/7/20 9:47 PM, Nick Bowler wrote: On 1/7/20, Martin Liška wrote: nm -B detection fails to be detected with -flto and -fno-common CFLAGS: configure:6307: checking command to parse /usr/bin/nm -B output from gcc object [...] configure:6536: gcc -o conftest -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -fno-common -flto -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -fno-common -flto conftest.c conftstm.o >&5 conftest.c:18:12: error: variable 'nm_test_var' redeclared as function 18 | extern int nm_test_var(); |^ conftest.c:4:6: note: previously declared here 4 |relocations are performed -- see ld's documentation on pseudo-relocs. */ | ^ lto1: fatal error: errors during merging of translation units compilation terminated. As seen, I bet problem is in conftstm.o file (for which I can't see how it's created). Probably the file is missing declaration of nm_test_var and so that it's implicitly deduced to be int nm_test_var(). nm_test_var is defined as: char nm_test_var; The test works by running nm on this file, parsing the output, and then generating a C file which inserts references to all the exported symbols it finds. Then this is linked with the original file. With a "normal" compiler and -fno-common nm_test_var goes in BSS and will be marked "B" in the nm output. Hello. However, LTO breaks nm really badly and with -fno-common this variable gets marked as "T" in the nm output. Thank you for identification of the root cause. I've just created a nm issue for that: https://sourceware.org/bugzilla/show_bug.cgi?id=25355 That will fix the problem, so let's see. Thanks, Martin So it is indistinguishable from functions and when the C file is generated, a function declaration for nm_test_var is emitted (if it was correctly marked "B", then a variable declaration will be emitted). It's really unfortunate that LTO breaks nm in this way. But even if this configure test didn't fail I suspect subsequent users of $global_symbol_pipe will expect nm to work properly and it won't. I'm not 100% sure which libtool features will be affected by this configuration failure. It doesn't fatally stop the configure script. Probably dlpreopen won't work at all? It's also unfortunate that since there is no way to directly reference symbol values in standard C, a common way to do so is with dummy array or function declarations, and lo and behold LTO apparently breaks this too... Cheers, Nick
Re: checking command to parse /usr/bin/nm -B output from gcc object... failed
On 1/7/20 10:07 PM, Bob Friesenhahn wrote: On Tue, 7 Jan 2020, Nick Bowler wrote: On 1/7/20, Martin Liška wrote: nm -B detection fails to be detected with -flto and -fno-common CFLAGS: I don't know what vintage this documentation is (the copyright says it is from 2020 so it seems to be the latest), but the page at https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html says this about "-fcommon" Yes, this one is for current master and we always document option that is _NOT_ a default. That's why you'll see documented -fno-common in GCC 9.2.0 manual: https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Code-Gen-Options.html Martin "The default is -fno-common, which specifies..." GCC 9.2 documentation says that the default is target dependent, which suggests that some targets use no-common by default. I'm not 100% sure which libtool features will be affected by this configuration failure. It doesn't fatally stop the configure script. Probably dlpreopen won't work at all? Are there many users of dlpreopen()? It's also unfortunate that since there is no way to directly reference symbol values in standard C, a common way to do so is with dummy array or function declarations, and lo and behold LTO apparently breaks this too... LTO often causes strange issues. It needs to be used with care. Thus far I have seen LTO reduce the output executable size (sometimes substantially if there is a lot of "dead" code) but I have not seen a speed benefit to properly written code. Bob
Re: checking command to parse /usr/bin/nm -B output from gcc object... failed
On 1/7/20 10:40 PM, Nick Bowler wrote: On 1/7/20, Bob Friesenhahn wrote: On Tue, 7 Jan 2020, Nick Bowler wrote: On 1/7/20, Martin Liška wrote: nm -B detection fails to be detected with -flto and -fno-common CFLAGS: I don't know what vintage this documentation is (the copyright says it is from 2020 so it seems to be the latest), but the page at https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html says this about "-fcommon" "The default is -fno-common, which specifies..." GCC 9.2 documentation says that the default is target dependent, which suggests that some targets use no-common by default. I think the fact that this test produces a common symbol most of the time, and that nm happens to work under LTO in this specific case, is mostly just a happy accident. Well, the nm is using LTO plugin, so it should properly communicate symbol types (in ideal world) :) I'm not 100% sure which libtool features will be affected by this configuration failure. It doesn't fatally stop the configure script. Probably dlpreopen won't work at all? Are there many users of dlpreopen()? I imagine there are users of -dlopen, which is supposed to automatically fall back to dlpreopen when shared library support is not available (for example, if the user configures the package with --disable-shared). Whether or not developers routinely test that their packages work with shared libraries disabled is another matter. Regardless, $global_symbol_pipe is part of the documented libtool interface, which says you can do: eval "$NM progname | $global_symbol_pipe" This is obviously busted because the failed configure test leads to global_symbol_pipe='' which will obviously cause problems in this usage (I just tested one of my scripts and yup, it is busted). Yes, that's what I see for many package failures in openSUSE when I enable -fno-common in optimization flags: But more importantly I suspect the actual busted feature is $global_symbol_to_cdecl, which is supposed to produce declarations for the symbols you get from global_symbol_pipe. This is clearly not working under LTO as it fails to distinguish functions and variables. It might be possible to detect this case in configure and come up with a symbol declaration that works for both functions and data, which might enable global_symbol_to_cdecl to generate working declarations, and would probably fix this configure test and typical usage scenarios like dlpreopen. It's also unfortunate that since there is no way to directly reference symbol values in standard C, a common way to do so is with dummy array or function declarations, and lo and behold LTO apparently breaks this too... LTO often causes strange issues. It needs to be used with care. Thus far I have seen LTO reduce the output executable size (sometimes substantially if there is a lot of "dead" code) but I have not seen a speed benefit to properly written code. When I last played around with LTO on my C code I was hoping to achieve reduced executable size but I found the results to be almost exactly the same as what I was already getting by compiling everything with -ffunction-sections -fdata-sections and then linking with -Wl,--gc-sections. And unlike LTO, those options don't break nm which would have required a massive amount of futzing with the build system to get things to even work. I can provide quite some interesting numbers about usage of LTO (ideally with PGO): http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html Or if you want to compare SPEC numbers: https://lnt.opensuse.org/db_default/v4/SPEC/spec_report/branch In both scenarios LTO brings both speed up and size reduction. And note that we enabled LTO in openSUSE Tumbleweed by default. Martin Cheers, Nick
Re: checking command to parse /usr/bin/nm -B output from gcc object... failed
On 1/8/20 10:16 AM, Martin Liška wrote: On 1/7/20 9:47 PM, Nick Bowler wrote: On 1/7/20, Martin Liška wrote: nm -B detection fails to be detected with -flto and -fno-common CFLAGS: configure:6307: checking command to parse /usr/bin/nm -B output from gcc object [...] configure:6536: gcc -o conftest -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -fno-common -flto -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -fno-common -flto conftest.c conftstm.o >&5 conftest.c:18:12: error: variable 'nm_test_var' redeclared as function 18 | extern int nm_test_var(); | ^ conftest.c:4:6: note: previously declared here 4 | relocations are performed -- see ld's documentation on pseudo-relocs. */ | ^ lto1: fatal error: errors during merging of translation units compilation terminated. As seen, I bet problem is in conftstm.o file (for which I can't see how it's created). Probably the file is missing declaration of nm_test_var and so that it's implicitly deduced to be int nm_test_var(). nm_test_var is defined as: char nm_test_var; The test works by running nm on this file, parsing the output, and then generating a C file which inserts references to all the exported symbols it finds. Then this is linked with the original file. With a "normal" compiler and -fno-common nm_test_var goes in BSS and will be marked "B" in the nm output. Hello. However, LTO breaks nm really badly and with -fno-common this variable gets marked as "T" in the nm output. Thank you for identification of the root cause. I've just created a nm issue for that: https://sourceware.org/bugzilla/show_bug.cgi?id=25355 So apparently it's a known limitation of the LTO plugin. Question is whether we can somehow workaround that? Martin That will fix the problem, so let's see. Thanks, Martin So it is indistinguishable from functions and when the C file is generated, a function declaration for nm_test_var is emitted (if it was correctly marked "B", then a variable declaration will be emitted). It's really unfortunate that LTO breaks nm in this way. But even if this configure test didn't fail I suspect subsequent users of $global_symbol_pipe will expect nm to work properly and it won't. I'm not 100% sure which libtool features will be affected by this configuration failure. It doesn't fatally stop the configure script. Probably dlpreopen won't work at all? It's also unfortunate that since there is no way to directly reference symbol values in standard C, a common way to do so is with dummy array or function declarations, and lo and behold LTO apparently breaks this too... Cheers, Nick
libtool: link: cannot find the library `'
Hello! I've searche dthe web and found some references to a strange patch and -lpthread stuff but nothing that would help me: /bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -o evote-client -static-libgcc -static -L/usr/lib evote_client-basemanager.o evote_client-dummymanager.o evote_client-electionui.o evote_client-myerror.o evote_client-electionuimain.o evote_client-evotecert.o evote_client-electionmanager.o evote_client-hesconnector.o evote_client-SSLCon.o evote_client-cyberdoclib.o evote_client-lin_https.o evote_client-lin_p11.o dynwarning.o evote_client-lin_digicrypt.o esteid.o evote_client-moc_electionui.o -lssl -lcrypto -framework Carbon -framework QuickTime -framework OpenGL -framework AGL -L/Developer/qt/lib -lqt -lz http/libhttp.la -Wl,-framework,CoreFoundation libtool: link: cannot find the library `' make[3]: *** [evote-client] Error 1 So i have no idea how it comes or what should i do to fix it. Using osx 10.4.2 and fink Information that might be relevant: ./libtool --version ltmain.sh (GNU libtool) 1.5.20 (1.1220.2.287 2005/08/31 18:54:15) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. autoconf --version autoconf (GNU Autoconf) 2.59 Written by David J. MacKenzie and Akim Demaille. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Darwin laptop.lan 8.2.0 Darwin Kernel Version 8.2.0: Fri Jun 24 17:46:54 PDT 2005; root:xnu-792.2.4.obj~3/RELEASE_PPC Power Macintosh powerpc -- Martin Paljak [EMAIL PROTECTED] http://martin.paljak.pri.ee/ +372.5156495 - phone ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool: link: cannot find the library `'
Hi, On 9/9/05, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Thanks for reporting this. > > Please post contents of http/libhttp.la, and the output of the above > command with "--debug" added before "--tag=CXX". Everything should be attached - the debug used to link libhttp and its makefile.am as well as the other libtool link command debug. Thanks, m. -- Martin Paljak [EMAIL PROTECTED] http://martin.paljak.pri.ee/ +372.5156495 - phone debugs.tar.gz Description: GNU Zip compressed data libhttp.la Description: Binary data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool: link: cannot find the library `'
I forgot to mention that it woks fine on debian unstable (libtool 1.5.6 and autoconf 2.59) m. On 9/9/05, Martin Paljak <[EMAIL PROTECTED]> wrote: > Hi, > On 9/9/05, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > Thanks for reporting this. > > > > Please post contents of http/libhttp.la, and the output of the above > > command with "--debug" added before "--tag=CXX". > > Everything should be attached - the debug used to link libhttp and its > makefile.am as well as the other libtool link command debug. > > Thanks, > m. > > -- > Martin Paljak > [EMAIL PROTECTED] > http://martin.paljak.pri.ee/ > +372.5156495 - phone > > > -- Martin Paljak [EMAIL PROTECTED] http://martin.paljak.pri.ee/ +372.5156495 - phone ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool: link: cannot find the library `'
On 9/9/05, Peter O'Gorman <[EMAIL PROTECTED]> wrote: > > Unfortunately the trolltech folks install a libqt.la that they hand-make. It > is not made by libtool, and it has the "dependency_libs='-framework Carbon'" > or some such in it. I attach the libqt.la file that was generated by qt 3.3.4. I'm currently building qt 3.3.5 snapshot - maybe that will change something. > Either remove the libqt.la or use libtool-2.0 in your project. Yes, I know > that 2.0 has not been released yet. Hmm, i just thought that using libtool and all the auto tools is a GoodThing and maybe libtool helps to do 'one big static binary' with ease... where can i get libtool 2.0 or further information ? -- Martin Paljak [EMAIL PROTECTED] http://martin.paljak.pri.ee/ +372.5156495 - phone libqt.la Description: Binary data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool: link: cannot find the library `'
On 9/9/05, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: Hmm, this patch helps and proves the -framework Carbon thing: libtool: link: cannot find the library `' or unhandled argument `Carbon' What could i do to fix it? only option to use libtool-2.0 ? would that work with the .la file provided by trolltech folks ? Or can i hack the libqt.la file to make it work ? Thanks, m. -- Martin Paljak [EMAIL PROTECTED] http://martin.paljak.pri.ee/ +372.5156495 - phone ___ http://lists.gnu.org/mailman/listinfo/libtool
Support for Interix 5.2 and 6.0?
Hello, libtool support for Interix 3.5 aka Microsoft Services for Unix is great. Unfortunately it currently only works for Interix 3.5, not for the 5.2 version included in Windows Server 2003 R2, and not for the 6.0 version included in Vista. Basically, building the libs is the same, but recent config.guess recognizes 2003 R2 as "i586-pc-interix5.2" and Vista as "i586-pc-interix6.0", while libtool.m4 only checks for "interix3*". I now did s/interix3/interix/ on libtool.m4, followed by ./bootstrap followed by ./configure and make on 2003 R2. make check test results are as follows: ... FAIL: hardcode.test ... 1 of 112 tests failed Please report to bug-libtool@gnu.org This is exactly as with Interix 3.5. So please consider doing s/interix3/interix/ on libtool.m4 before releasing 1.5.23. This may have some impact on Interix 2.x, but as 3.5 is now available for free and 3.0 should work as before, it shouldn't matter that much. Thank you very much Martin ___ http://lists.gnu.org/mailman/listinfo/libtool
Support for Interix 5.2 and 6.0
Hello, libtool's support for Interix 3.5 aka Microsoft Services for Unix is great. Unfortunately it currently only works for Interix 3.5, not for the 5.2 version included in Windows Server 2003 R2, and not for the 6.0 version included in Vista. Basically, building the libs is the same, but recent config.guess recognizes 2003 R2 as "i586-pc-interix5.2" and Vista as "i586-pc-interix6.0", while libtool.m4 only checks for "interix3*". I now did s/interix3/interix/ on libtool.m4, followed by ./bootstrap followed by ./configure and make on 2003 R2. make check test results are as follows: ... FAIL: hardcode.test ... 1 of 112 tests failed Please report to bug-libtool@gnu.org This is exactly as with Interix 3.5. So please consider doing s/interix3/interix/ on libtool.m4 before releasing 1.5.23. This may have some impact on Interix 2.x, but as 3.5 is now available for free and 3.0 should work as before, it shouldn't matter that much. Thank you very much Martin ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool 1.4.2: Enhancement request
Hello, I recently installed ethereal (0.9.3). I had one problem, which is libtool related: > I configured using: > export CC=cc > export CPPFLAGS="-I/pd/libs/include/" > export LDFLAGS=" -L/pd/libs/lib/" > export CFLAGS="+DAportable -Ae +O2" > ./configure -prefix=/pd/ethereal0.9.3 --without-gcc --includedir=/pd/libs/include >--libdir=/pd/libs/lib > Making worked, with one glitch: > I include '+DAportable' in the CFLAGS, because I build on a PA2.0 machine, but the > executable might later be used on PA1.1 machines. > make missed this flag for one file: > ... > (cd .libs && cc -c +Z -DPIC +DAportable "etherealS.c") > ... > > I finally "fixed" this by adding +DAportable in ltmain.sh (line 3375) > [and configure/make again]: > *-*-hpux*) > case "$compile_command " in > *" -static "*) ;; > *) pic_flag_for_symtable=" $pic_flag -DPIC +DAportable";; ><= > esac > > Could the flags from CFLAGS used here without manual intervention ?! Guy Harris (from the ethereal project) pointed me to libtool too report this. According to what I found in ltmain.sh, ethereal is using libtool 1.4.2. Please let me know, if you need additional info on this. Thanks Martin ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Shared C++ libraries on AIX
Hello, I'm having trouble when trying to built shared C++ libraries on AIX 4.3 with libtool 1.4.2 and also 1.4d. I'm using IBM C/C++ compiler 3.6.6. The first problem is nm utility. Libtool lists public symbols in all .o files and creates export file from them. However, "nm -B" on AIX by default demangles all C++ identifiers and therefore these are not listed in export file. Extra option -C must be added to force nm not to demangle C++. Second problem is with linking itself. Libtool passes -lc to linker but -lC (or -lC_r for reentrant version) should be used. When not used, link passes without problems but later when library invokes new operator, core dump occurs. Are there any suggestions regarding these issues? Thanks Martin ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Shared C++ libraries on AIX
Thanks for suggestion but this is even worse (CVS main trunk, 2002-10-07
- version 1.4e):
source='sub1.cpp' object='sub1.lo' libtool=yes
depfile='.deps/sub1.Plo' tmpdepfile='.deps/sub1.TPlo' depmode=aix
/bin/sh ./depcomp /bin/sh ./libtool --mode=compile xlC
-DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"cpplibtest\"
-DVERSION=\"0.1\" -D_ALL_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I. -g -c -o sub1.lo `test
-f "sub1.cpp" || echo './'`sub1.cpp
./libtool[338]: s%^.*/%%: not found.
./libtool[410]: -e: not found
: warning: cannot infer operation mode from `xlC'
: you must specify a MODE
Try ` --help' for more information.
make: 1254-004 The error code from the last command is 1.
This is on line 338:
progname=`$echo "$0" | ${SED} 's%^.*/%%'`
The problem is with SED variable, it is not defined anywhere in libtool
script. I think the CVS version is currently unstable.
Martin
Bob Friesenhahn wrote:
> Try using CVS libtool instead. It is designed to support C++, and
> usually uses the C++ compiler to link C++ objects.
>
> Bob
>
> On Mon, 7 Oct 2002, Martin Frydl wrote:
>
>
>>Hello,
>>
>> I'm having trouble when trying to built shared C++ libraries on AIX
>>4.3 with libtool 1.4.2 and also 1.4d. I'm using IBM C/C++ compiler 3.6.6.
>>
>> The first problem is nm utility. Libtool lists public symbols in all
>>.o files and creates export file from them. However, "nm -B" on AIX by
>>default demangles all C++ identifiers and therefore these are not listed
>>in export file. Extra option -C must be added to force nm not to
>>demangle C++.
>>
>> Second problem is with linking itself. Libtool passes -lc to linker
>>but -lC (or -lC_r for reentrant version) should be used. When not used,
>>link passes without problems but later when library invokes new
>>operator, core dump occurs.
>>
>> Are there any suggestions regarding these issues?
>>
>> Thanks
>> Martin
>>
>>
>>
>>___
>>Libtool mailing list
>>[EMAIL PROTECTED]
>>http://mail.gnu.org/mailman/listinfo/libtool
>>
>
>
> ==
> Bob Friesenhahn
> [EMAIL PROTECTED]
> http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Shared C++ libraries on AIX
I've installed CVS libtool to wrong directory so aclocal used different
libtool.m4. My mistake, now everything works fine.
Thank you for your help.
Martin
Ossama Othman wrote:
> Hi,
>
> On Mon, Oct 07, 2002 at 07:01:04PM +0200, Martin Frydl wrote:
>
>>progname=`$echo "$0" | ${SED} 's%^.*/%%'`
>>
>>The problem is with SED variable, it is not defined anywhere in libtool
>>script. I think the CVS version is currently unstable.
>
>
> Did you run aclocal in your package to pull in the latest libtool M4
> macros? Some of libtool's functionality is now at done at
> `configure'-time, meaning that you have to pull in the latest libtool
> M4 macros.
>
> HTH,
> -Ossama
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
compiling from cvs
Hi, what is the proper was to compile libtool from cvs? I cannot find it in README or doc/*. :( $ aclocal $ automake configure.ac: required file `./install-sh' not found configure.ac: required file `./mkinstalldirs' not found configure.ac: required file `./missing' not found Makefile.am: required file `./COPYING' not found Makefile.am: required file `./INSTALL' not found configure.ac:128: required file `./ltmain.sh' not found doc/Makefile.am:4: required file `doc/mdate-sh' not found doc/Makefile.am:4: required file `doc/texinfo.tex' not found $ autoconf configure.ac:115: error: possibly undefined macro: LT_AC_PROG_GCJ If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:118: error: possibly undefined macro: LT_AC_PROG_RC $ autoconf (GNU Autoconf) 2.57 automake (GNU automake) 1.7.2 gettext (GNU gettext) 0.11.5 Tru64Unix/OSF1 5.1A -- Martin Mokrejs <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs MIPS / Institute for Bioinformatics <http://mips.gsf.de> GSF - National Research Center for Environment and Health Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany tel.: +49-89-3187 3683 , fax: +49-89-3187 3585 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: compiling from cvs
On Sat, 7 Dec 2002, Martin MOKREJŠ wrote:
Hi,
thank you for quick responses. The reason I want to have new libtool is,
that I'm facing problems compiling gtk+ on my machine. I was told I've hit
libtool bug:
/bin/bash ../libtool --mode=link cc -O2 -arch ev6 -I/software/@sys/usr/include
-I/usr/local/include -I/usr/local/openssl/include
-I/software/@sys//usr/include/freetype2 -L/usr/local/lib -L/software/@sys/usr/lib
-L/usr/local/openssl/lib -L/usr/lib -o libgdk_pixbuf-2.0.la -rpath
/software/@sys/usr/lib -version-info 0:9:0 -export-symbols-regex "^[^_].*"
gdk-pixbuf.lo gdk-pixbuf-animation.lo gdk-pixbuf-data.lo gdk-pixbuf-io.lo
gdk-pixbuf-loader.lo gdk-pixbuf-scale.lo gdk-pixbuf-util.lo gdk-pixdata.lo
gdk-pixbuf-enum-types.lo pixops/libpixops.la -L/software/@sys/usr/lib -lgmodule-2.0
-lgobject-2.0 -lglib-2.0 -lintl -liconv-lm -L/usr/local/lib
-L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -liconv -lintl -liconv
mkdir .libs
rm -fr .libs/libgdk_pixbuf-2.0.la .libs/libgdk_pixbuf-2.0.* .libs/libgdk_pixbuf-2.0.*
(cd . && ln -s gdk-pixbuf.lo gdk-pixbuf.o)
(cd . && ln -s gdk-pixbuf-animation.lo gdk-pixbuf-animation.o)
(cd . && ln -s gdk-pixbuf-data.lo gdk-pixbuf-data.o)
(cd . && ln -s gdk-pixbuf-io.lo gdk-pixbuf-io.o)
(cd . && ln -s gdk-pixbuf-loader.lo gdk-pixbuf-loader.o)
(cd . && ln -s gdk-pixbuf-scale.lo gdk-pixbuf-scale.o)
(cd . && ln -s gdk-pixbuf-util.lo gdk-pixbuf-util.o)
(cd . && ln -s gdk-pixdata.lo gdk-pixdata.o)
(cd . && ln -s gdk-pixbuf-enum-types.lo gdk-pixbuf-enum-types.o)
generating symbol list for `libgdk_pixbuf-2.0.la'
/usr/bin/nm -B gdk-pixbuf.o gdk-pixbuf-animation.o gdk-pixbuf-data.o gdk-pixbuf-io.o
gdk-pixbuf-loader.o gdk-pixbuf-scale.o gdk-pixbuf-util.o gdk-pixdata.o
gdk-pixbuf-enum-types.o pixops/.libs/libpixops.al | sed -n -e 's/^.*[
]\([BCDEGQRST][BCDEGQRST]*\)[ ][ ]*\(\)\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2\3 \3/p'
| sed 's/.* //' | sort | uniq > .libs/libgdk_pixbuf-2.0.exp
egrep -e "^[^_].*" ".libs/libgdk_pixbuf-2.0.exp" > ".libs/libgdk_pixbuf-2.0.expT"
mv -f ".libs/libgdk_pixbuf-2.0.expT" ".libs/libgdk_pixbuf-2.0.exp"
rm -fr .libs/libgdk_pixbuf-2.0.lax
mkdir .libs/libgdk_pixbuf-2.0.lax
rm -fr .libs/libgdk_pixbuf-2.0.lax/libpixops.al
mkdir .libs/libgdk_pixbuf-2.0.lax/libpixops.al
(cd .libs/libgdk_pixbuf-2.0.lax/libpixops.al && ar x
/scratch/gtk+-2.0.9/gdk-pixbuf/pixops/.libs/libpixops.al)
for i in `cat .libs/libgdk_pixbuf-2.0.exp`; do printf "-exported_symbol " >>
.libs/libgdk_pixbuf-2.0.so.0.0.9.exp; echo "$i" >>
.libs/libgdk_pixbuf-2.0.so.0.0.9.exp; done; echo "-hidden">>
.libs/libgdk_pixbuf-2.0.so.0.0.9.exp
../libtool: printf: illegal option: -e
printf: usage: printf format [arguments]
../libtool: printf: illegal option: -e
[...]
printf: usage: printf format [arguments]
../libtool: printf: illegal option: -e
printf: usage: printf format [arguments]
/usr/bin/ld -shared -expect_unresolved \* -input .libs/libgdk_pixbuf-2.0.so.0.0.9.exp
gdk-pixbuf.o gdk-pixbuf-animation.o gdk-pixbuf-data.o gdk-pixbuf-io.o
gdk-pixbuf-loader.o gdk-pixbuf-scale.o gdk-pixbuf-util.o gdk-pixdata.o
gdk-pixbuf-enum-types.o .libs/libgdk_pixbuf-2.0.lax/libpixops.al/pixops.lo -rpath
/software/@sys/usr/lib -L/usr/local/lib -L/software/@sys/usr/lib
-L/usr/local/openssl/lib -L/usr/lib pixops/.libs/libpixops.al -R/software/@sys/usr/lib
-lc /software/@sys/usr/lib/libgmodule-2.0.so /software/@sys/usr/lib/libgobject-2.0.so
/software/@sys/usr/lib/libglib-2.0.so -lm /software/@sys/usr/lib/libintl.so
/software/@sys/usr/lib/libiconv.so -lc -soname libgdk_pixbuf-2.0.so.0 `test -n
"0.0.9:0.0" && echo -set_version 0.0.9:0.0` -update_registry .libs/so_locations -o
.libs/libgdk_pixbuf-2.0.so.0.0.9
/usr/bin/ld:
Can't open: gdk_colorspace_get_type (No such file or directory)
make[3]: *** [libgdk_pixbuf-2.0.la] Error 1
make[3]: Leaving directory `/usr/local/scratch/gtk+-2.0.9/gdk-pixbuf'
The problem above I'm able to fix temporarily:
--- libtool.ori 2002-12-07 20:26:43.0 +0100
+++ libtool 2002-12-07 20:28:02.0 +0100
@@ -185,7 +185,7 @@
# Commands used to build and install a shared archive.
archive_cmds="\$LD -shared\${allow_undefined_flag} \$libobjs \$deplibs \$linker_flags
-msym -soname \$soname \\\`test -n \\\"\$verstring\\\" && echo -set_version
\$verstring\\\` -update_registry \${output_objdir}/so_locations -o \$lib"
-archive_expsym_cmds="for i in \\\`cat \$export_symbols\\\`; do printf
\\\"-exported_symbol \\\" >> \$lib.exp; echo \\\"\\\$i\\\" >> \$lib.exp; done; echo
\\\"-hidden\\\">> \$lib.exp~
+archive_expsym_cmds="for i in \\\`cat \$export_symbols\\\`; do /usr/bin/printf
+\\\"-expor
Exceptions in shared lib with icc on Linux
Hello, I've found problem when throwing exception from shared library when compiled with icc on Linux. I've attached a test case. The source of this problem is probably linking against c library. Libtool uses this command line: icpc -shared -nostdlib .libs/sub1.o -lc -Qoption,ld,-soname \ -Qoption,ld,libshr.so.0 -o .libs/libshr.so.0.0.0 When I remove -nostdlib and -lc from command line, exe runs without problems. Am I doing something wrong? I've passed CC=icc CXX=icpc to configure. I'm using CVS version of libtool. Thanks Martin iccexctest.tgz Description: GNU Zip compressed data ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Exceptions in shared lib with icc on Linux
Albert Chin wrote: On Mon, Jan 06, 2003 at 05:29:04PM +0100, Martin Frydl wrote: I've found problem when throwing exception from shared library when compiled with icc on Linux. I've attached a test case. The source of this problem is probably linking against c library. Libtool uses this command line: icpc -shared -nostdlib .libs/sub1.o -lc -Qoption,ld,-soname \ -Qoption,ld,libshr.so.0 -o .libs/libshr.so.0.0.0 When I remove -nostdlib and -lc from command line, exe runs without problems. What if you remove only -lc? The problem persists. I have to remove both -lc and -nostdlib. Martin ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Exceptions in shared lib with icc on Linux
I've looked into it and found two places which almost always rewrite archive_cmds_need_lc to yes. Both are in libtool.m4. Line 3412: case " $_LT_AC_TAGVAR(postdeps, $1) " in *" -lc "*) _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no ;; *) _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=yes ;; esac Since postdeps for icc does not contain -lc, archive_cmds_need_lc is set to yes. I haven't looked how postdeps are determined but this looks like -lc is always used - either it is in postdeps or added later due to archive_cmds_need_lc=yes. Line 5402: Here archive_cmds_need_lc is always set to yes and only if used compiler is gcc, it may be reset to no. I don't know why the two places above don't honour previous value of archive_cmds_need_lc. I've commented out both lines setting yes and built was successful (I've also modified line 2937 - removed -nostdlib). The built with gcc and Sun's CC was also successful, but this is definitelly not a correct solution. Martin Robert Boehne wrote: Albert, I think it may be that an Autoconf macro is re-setting this later on. I seem to get "archive_cmds_need_lc=yes" in nearly every case I look at. Robert Albert Chin wrote: On Mon, Jan 06, 2003 at 05:29:04PM +0100, Martin Frydl wrote: I've found problem when throwing exception from shared library when compiled with icc on Linux. I've attached a test case. The source of this problem is probably linking against c library. Libtool uses this command line: icpc -shared -nostdlib .libs/sub1.o -lc -Qoption,ld,-soname \ -Qoption,ld,libshr.so.0 -o .libs/libshr.so.0.0.0 Odd that -lc got in there. From libtool.m4 in CVS: icpc) # Intel C++ with_gnu_ld=yes _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no I presume archive_cmds_need_lc=no means that -lc should not be added. Anyone know more? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Dynamic library lookup on HP-UX
I have problems with hardcoded paths to shared libraries on HP-UX. When libtool creates executable or shared library, it hardcodes paths to any dependency libraries into it and disable dynamic lookup according to SHLIB_PATH shell variable. Now when I move the library to different directory, dynamic linker is unable to find it (unless I use chatr utility to allow SHLIB_PATH lookup). In fact my problem is little different. I have two libraries (OpenSSL), one dependent on another: libssl needs libcrypto. However, libssl does not have hardcoded path to libcrypto (both are in the same directory). When I create executable using both libraries, libtool hardcodes paths to these libraries into it. So far it looks good. However, when I run the executable, dynamic linker complains about libssl - it says it cannot find dependency library libcrypto. I think the problem here is that dynamic linker "thinks" libcrypto referenced from executable is different library than libcrypto referenced from libssl. The solution here is to either pass +s linker flag or perform post-build step - "chatr +s enable" - for the executable (and any shared libraries which use OpenSSL and can be dlopened). I remember the discussions about this last year but I'm not sure about their result (chatr is not used in libtool). What is the right way to allow SHLIB_PATH lookup? Should this be solved by libtool or should I solve it manually (i.e. pass LDFLAGS=-Wl,+s)? I use autoconf 2.57, automake 1.7.1 and CVS libtool: ltmain.sh (GNU libtool) 1.4e (1.1210 2003/03/25 23:53:38) -- Martin References: http://mail.gnu.org/archive/html/libtool/2002-05/msg00054.html http://mail.gnu.org/archive/html/automake/2002-09/msg00148.html ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Compiling 32-bit code on 64-bit HP-UX
Hello,
I'm trying to create 32-bit shared libraries on 64-bit PA-RISC 2.0
(HP-UX 11) with aCC compiler. I have several libraries and executables
in my project. When I run them from build directory, everything works
fine. However, when I run make install and delete build directory, the
executables and libraries stop working. I've looked into them via chatr
utility and it shows that they reference build directory as search path,
not install one.
I've investigated the problem and it looks like it lies in
config.guess. config.guess checks host type according to uname and
getconf utility which results in "hppa2.0w" (64-bit PA-RISC 2.0). Then
there is a check for __LP64__ define, which fails. Here the failure is
caused by wrong use of compiler options - it runs:
$CC_FOR_BUILD -E -
which is not understood by aCC. It should be rewritten to use
temporary file instead of "-" (stdin). Moreover, the check does not use
compiler flags so the result is not affected by switches determining the
"bitness" of resulting code - +DA2.0W (64-bit), +DA2.0N (32-bit), +DA1.1
(32-bit PA-RISC 1.1). However, this can be workarounded by putting these
directly into CC when running configure.
The host type set after the check is not clear enough since it does
not correspond to aCC options. When __LP64__ is defined, host type is
hppa64, which seems correct if it stands for 64-bit. When the check
fails, host type is set to hppa2.0w. However, I think this host type
should mean 64-bit since option +DA2.0W to aCC generates 64-bit code.
Unfortunatelly, libtool determines 32/64-bit hppa in a way "hppa64 is
64-bit and anything else is 32-bit". There is also problem in libtool.m4
regarding options supplied via CC variable. When they are supplied,
libtool checks for compiler do not work since cc_basename contains also
those options. I've attached simple patch which removes all characters
after the first space.
Also I don't understand the way config.guess should be copied to
project. Currently it is copied by libtoolize from share/libtool, but
this one is outdated and current one is in share/automake-1.7. Should I
copy it manually from automake?
Now here are my conclusions:
- config.guess does not use CFLAGS when making compilation checks but
this can be "fixed" by providing necessary flags directly in CC variable
- config.guess should be fixed so __LP64__ check works corretly (patch
attached)
- config.guess "generates" host types which do not correspond to aCC (HP
native) namings but this cannot be changed
- there are two config.guess versions when both libtool and automake are
installed. libtoolize takes one from libtool, not automake
- libtool needs to be patched to support options supplied in CC or CXX
variables
Martin
--- share/libtool/config.guess Thu Sep 11 20:42:41 2003
+++ config.guessThu Sep 11 20:48:01 2003
@@ -622,7 +622,8 @@
then
# avoid double evaluation of $set_cc_for_build
test -n "$CC_FOR_BUILD" || eval $set_cc_for_build
- if echo __LP64__ | (CCOPTS= $CC_FOR_BUILD -E -) | grep __LP64__ >/dev/null
+ echo __LP64__ > $dummy.c
+ if (CCOPTS= $CC_FOR_BUILD -E $dummy.c) | grep __LP64__ >/dev/null
then
HP_ARCH="hppa2.0w"
else
--- share/aclocal/libtool.m4Thu Sep 11 20:42:41 2003
+++ libtool.m4 Thu Sep 11 21:55:40 2003
@@ -2655,7 +2655,7 @@
CC=${CXX-"c++"}
compiler=$CC
_LT_AC_TAGVAR(compiler, $1)=$CC
-cc_basename=`$echo X"$compiler" | $Xsed -e 's%^.*/%%'`
+cc_basename=`$echo X"$compiler" | $Xsed -e 's%^.*/%%' | $Xsed -e 's% .*$%%'`
# We don't want -fno-exception wen compiling C++ code, so set the
# no_builtin_flag separately
@@ -3648,7 +3648,7 @@
CC=${F77-"f77"}
compiler=$CC
_LT_AC_TAGVAR(compiler, $1)=$CC
-cc_basename=`$echo X"$compiler" | $Xsed -e 's%^.*/%%'`
+cc_basename=`$echo X"$compiler" | $Xsed -e 's%^.*/%%' | $Xsed -e 's% .*$%%'`
AC_MSG_CHECKING([if libtool supports shared libraries])
AC_MSG_RESULT([$can_build_shared])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Compiling 32-bit code on 64-bit HP-UX
Boehne, Robert wrote: Martin, Even on a 64-bit capable machine, aCC defaults to 32-bit libraries. Having config.guess return hppa2.0w does not change the output that is produced, aCC will produce whatever you tell it to (32-bit by default). When you're running a configure script you want to set both (for C) CPPFLAGS and CFLAGS, for C++ CXXCPPFLAGS and CXXFLAGS when you need to pass an option that changes the preprocessing like +DA. This is generally a better option than setting CXX="aCC -DA2.0". Try this and read the Libtool web site regarding contributing if you want to send another patch. http://www.gnu.org/software/libtool/contribute.html Unfortunatelly, this solution does not work. libtool determines its operation (whether compiling 32 or 64-bit code) according to host type set by config.guess. This seems ok. config.guess makes test to check whether the compiler generates 32 or 64-bit code. However, the problem is that it uses just CC and ignores all flags (including your suggested). The only solution is to pass them via CC (I've seen this trick some time ago in libtool mailing list). When this trick is used, host type is hppa64 and libtool works correctly. The problem is that it does not recognize the compiler now - that's fixed by the patch. I think this patch also fixes problem discussed some time ago on mailing list - about Intel icc compiler. It was solved by adding extra "*" to branches in "case $cc_basename". Now it should work without them. See http://mail.gnu.org/archive/html/libtool/2003-04/msg00016.html (I haven't tried this, it's just my assumption). BTW, +DA2.0 is not preprocessor option, but the compiler one. It determines architecture where the generated code will run - note the plus "+" before D instead of minus "-". Martin HTH, Robert -Original Message- From: Martin Frydl [mailto:[EMAIL PROTECTED] Sent: Thursday, September 11, 2003 3:14 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Compiling 32-bit code on 64-bit HP-UX Hello, I'm trying to create 32-bit shared libraries on 64-bit PA-RISC 2.0 (HP-UX 11) with aCC compiler. I have several libraries and executables in my project. When I run them from build directory, everything works fine. However, when I run make install and delete build directory, the executables and libraries stop working. I've looked into them via chatr utility and it shows that they reference build directory as search path, not install one. I've investigated the problem and it looks like it lies in config.guess. config.guess checks host type according to uname and getconf utility which results in "hppa2.0w" (64-bit PA-RISC 2.0). Then there is a check for __LP64__ define, which fails. Here the failure is caused by wrong use of compiler options - it runs: $CC_FOR_BUILD -E - which is not understood by aCC. It should be rewritten to use temporary file instead of "-" (stdin). Moreover, the check does not use compiler flags so the result is not affected by switches determining the "bitness" of resulting code - +DA2.0W (64-bit), +DA2.0N (32-bit), +DA1.1 (32-bit PA-RISC 1.1). However, this can be workarounded by putting these directly into CC when running configure. The host type set after the check is not clear enough since it does not correspond to aCC options. When __LP64__ is defined, host type is hppa64, which seems correct if it stands for 64-bit. When the check fails, host type is set to hppa2.0w. However, I think this host type should mean 64-bit since option +DA2.0W to aCC generates 64-bit code. Unfortunatelly, libtool determines 32/64-bit hppa in a way "hppa64 is 64-bit and anything else is 32-bit". There is also problem in libtool.m4 regarding options supplied via CC variable. When they are supplied, libtool checks for compiler do not work since cc_basename contains also those options. I've attached simple patch which removes all characters after the first space. Also I don't understand the way config.guess should be copied to project. Currently it is copied by libtoolize from share/libtool, but this one is outdated and current one is in share/automake-1.7. Should I copy it manually from automake? Now here are my conclusions: - config.guess does not use CFLAGS when making compilation checks but this can be "fixed" by providing necessary flags directly in CC variable - config.guess should be fixed so __LP64__ check works corretly (patch attached) - config.guess "generates" host types which do not correspond to aCC (HP native) namings but this cannot be changed - there are two config.guess versions when both libtool and automake are installed. libtoolize takes one from libtool, not automake - libtool needs to be patched to support options supplied in CC or CXX variables
nm prints warnings when processing stripped shared libraries
hoi :)
libtool uses nm to extract symbols from libraries:
for arg in $dlprefiles; do
$show "extracting global C symbols from \`$arg'"
name=`$echo "$arg" | ${SED} -e 's%^.*/%%'`
$run eval '$echo ": $name " >> "$nlist"'
$run eval "$NM $arg | $global_symbol_pipe >> '$nlist'"
done
If such a library is stripped (as is the case for all installed
libraries on this Debian system here), then nm complains that it
cannot find any symbols.
This is not bad per se, but very annoying when used with make -s and
libtool --silent as it prints a lot of false error messages.
Could libtool please redirect nm stderr to /dev/null or take other
actions to suppress the warning.
Or perhaps use objdump which uses stdout to print 'no symbols'.
--
Martin Waitz
signature.asc
Description: Digital signature
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Incompatible behaviour of AC_LIB_LTDL
Hi! In libtool 2 the behaviour of the (deprecated) AC_LIB_LTDL differs from what it was in 1.5. It now calls AC_CONFIG_SUBDIRS which it didn't do previously. I encountered this while building GNUnet on Gentoo Linux. There I got this message: $ aclocal -I m4 configure.ac:44: error: `libltdl' is already registered with AC_CONFIG_SUBDIRS. ../../lib/autoconf/status.m4:1092: AC_CONFIG_SUBDIRS is expanded from... /usr/share/aclocal/ltdl.m4:383: _LTDL_SETUP is expanded from... /usr/share/aclocal/ltdl.m4:242: LTDL_INIT is expanded from... /usr/share/aclocal/ltdl.m4:368: AC_LIB_LTDL is expanded from... configure.ac:44: the top level autom4te-2.62: /usr/bin/m4 failed with exit status: 1 aclocal-1.10: autom4te failed with exit status: 1 See also: http://bugs.gentoo.org/show_bug.cgi?id=220765 https://gnunet.org/mantis/view.php?id=1340 I would assume that functions should keep their semantics so that the config scripts won't need to check libtool versions to choose the right commands. This is especially true for deprecated functions only present for backward compatibility like AC_LIB_LTDL. Otherwise we'll soon need meta-auto-tools which configure the autotools input depending on autotools versions and features... I'm not subscribed to this list, but I hope this mail gets accepted anyway, and I'll try to keep track of the archives. Greetings, Martin von Gagern signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
