Re: [Automake] How to get debug symbols in the executable?
On 08/04/2012 07:10 PM, Marcelo Zimbres wrote: > Hi, > > I am having some trouble to debug programs built from autotools. I am > following the steps: > > $ ./configure CXXFLAGS="-g -O0" > $ make > $ libtool --mode=execute gdb --arg ./swat_find arg_list > > When I run the last line, I get the error message: > > Reading symbols from > /home/marcelo/Public/swat/debug/.libs/lt-swat_find...(no debugging symbols > found)...done. > > Why there are no symbols? The output of make shows the flags have been > passed to gcc, for example: > > libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include/root > -I/usr/local/include/root -I -I -g -O0 -MT libswat_la-TDKernel.lo -MD -MP > -MF .deps/libswat_la-TDKernel.Tpo -c ../TDKernel.cxx -o > libswat_la-TDKernel.o >/dev/null 2>&1 > So this is unlikely to be a problem with Automake (as the flags specified at configure time have been passed correctly to the libtool invocation at make runtime, as you noted). Thus I suggest you try to report your issue to the libtool list instead, to see if they have more ideas. So save you time, I've already CC:ed the libtool list in this reply. > I couldn't also find the -s option which would discard the symbols. Can > someone help me? > > Thanks, > Marcelo > > ps. I am using automake version 1.11.3 > And, for completeness, what autoconf and libtool versions? Regards, Stefano ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: [RFC] Moving ltmain.sh and libtool.m4 into Automake
On 10/17/2012 11:41 AM, Gary V. Vaughan wrote: > Autotoolers, > > For quite some time now I've been thinking about simplifying Libtool, > but I'm interested in feedback and more particularly buy-in from > Automake maintainers before I start the work, so that I have a better > idea of what direction I'm heading in... > > Libtool is just (a complicated) compiler wrapper, to make building and > linking against libraries easy to specify... be that on the command > line with a direct libtool invocation, or from Makefile.am > specifications. I'm considering splitting the current libtool project > in two: > > 1. libltdl as a standalone runtime loader wrapper > 2. libtool.m4/ltmain.sh to generate the libtool script > > I think (2) belongs better into Automake alongside the other tool > wrappers it already carries, where it can decide whether to run the > libtool m4 macros and roll an appropriate compiler wrapper tailored for > the project using it (no need for all the C++/Java/Fortran goo in a C- > only project for example). > > Another consideration is that rolling Libtool into Automake would make > using Libtool as a standalone script rather more difficult. Having > said that, my impression is that Libtool is rarely used that way in > any case, and further simplification may be possible by deliberately > dropping explicit support for that use case. > > If I make this split and contribute the macros and ltmain.sh to Automake, > is this something anyone else would like? If so, do you like it enough > to wire it into Automake with an appropriate hunk of Perl? > > If the consensus is that Automake is not a good home for the libtool > compiler wrapper, then I still plan to split Libtool into two projects > as outlined above to decouple and simplify somewhat -- although I have > some other things to attend to first, so it will not happen right away, > but more likely after the next release. > > Thoughts? > As I know very little about libtool, and as I'm going to have much less time in the near future to work on automake (and I'd rather spend that time working on Automake-NG), I'm unfortunately quite opposed to this change, at least for the moment being. Sorry. Apart from those "personal" considerations, I believe Automake should be made more easily "pluggable" rather than being bloated with yet more stuff into its core. Think of Autoconf: how messed up would that be if all the macros used by Gnulib would have to be integrated with it? Luckily, thanks to Autoconf easy extensibility, Gnulib is free to add all the extra checks and macros and wrapping code it needs without having to even touch the Autoconf code. That's the situation I'd like have for Automake, or for Automake-NG at least. The question of how to get there starting from the present situation is of course an open and difficult problem, but I still hope we could manage to solve it (at least partially) in the future. Regards, Stefano ___ https://lists.gnu.org/mailman/listinfo/libtool
Automake, Libtool and AM_PROG_AR (was: Re: bug#11401: automake-1.12 (incorrectly?) complains about missing AM_PROG_AR)
References: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11401> <http://lists.gnu.org/archive/html/automake/2012-05/msg00012.html> On 05/11/2012 01:37 PM, Stefano Lattarini wrote: > On 05/04/2012 09:19 PM, Mike Frysinger wrote: >> On Friday 04 May 2012 03:20:10 Peter Rosin wrote: >>> On 2012-05-04 07:25, Mike Frysinger wrote: >>>> >>>> $ cat configure.ac >>>> AC_PREREQ([2.63]) >>>> AC_INIT([foo], [0]) >>>> AM_INIT_AUTOMAKE([1.11 -Wall foreign]) >>>> AC_PROG_CC >>>> LT_INIT >>>> AC_OUTPUT(Makefile) >>>> >>>> $ cat Makefile.am >>>> lib_LTLIBRARIES = libfoo.la >>>> libfoo_la_SOURCES = foo.c >>>> >>>> with automake-1.11.5, everything works great, but with automake 1.12: >>>> >>>> $ autoreconf -f -i >>>>> ... >>>> ltlibrary.am: warning: 'libfoo.la': linking libtool libraries using a >>>> non-POSIX >>>> ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac' >>>> Makefile.am:1: while processing Libtool library 'libfoo.la' >>>> >>>> what gives ? >>> >>> If you don't want *all* warnings, don't ask for *all* warnings :-) >> >> not my code base ;) >> >>> It's in NEWS, from 1.12: >>> >>> - The warnings in the category 'extra-portability' are now enabled by >>> '-Wall'. In previous versions, one has to use '-Wextra-portability' >>> to enable them. >> >> ok, so the fact that it's warning via -Wall is new to 1.12, but the >> underlying >> issue (warning at all) is not >> > Exactly. > >>> which should be read in light of this from 1.11.2: >>> >>> - New macro AM_PROG_AR that looks for an archiver and wraps it in the new >>> 'ar-lib' auxiliary script if the selected archiver is Microsoft lib. >>> This new macro is required for LIBRARIES and LTLIBRARIES when automake >>> is run with -Wextra-portability and -Werror. >> >> imo, projects utilizing libtool shouldn't need to know this at all. the >> whole >> point is to hide these esoteric details behind a layer and focus on the bits >> that projects actually care about -- what sources to put into libraries, >> etc... so is the answer to update libtool to call AM_PROG_AR when it's >> available ? >> > It seems there might be consensus on this idea: > > <http://lists.gnu.org/archive/html/automake/2012-05/msg00012.html> > > If it will turn out that is actually the case, I will close this bug report > (the discussion will likely continue on the bug-libtool list). For now, let's > wait and see how things evolve. > Any news on this? Since it doesn't seem a big deal anyway, unless I hear something new in a few days, I'll go ahead and close the bug report, leaving the matter in the hands of the libtoolers. Regards, Stefano ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Automake, Libtool and AM_PROG_AR
On 11/21/2012 11:46 AM, Stefano Lattarini wrote: > References: > <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11401> > <http://lists.gnu.org/archive/html/automake/2012-05/msg00012.html> > > Any news on this? Since it doesn't seem a big deal anyway, unless I hear > something new in a few days, I'll go ahead and close the bug report, leaving > the matter in the hands of the libtoolers. > I've closed this report now. Regards, Stefano ___ https://lists.gnu.org/mailman/listinfo/libtool
