From: Ludovic Brenta on 14 May 2010 16:38 Dmitry A. Kazakov writes: > On Fri, 14 May 2010 20:43:27 +0200, Ludovic Brenta wrote: > >> ยง 5.3.3 Ada object files [...] >> Rule: The -dev package SHALL provide a static library in >> /usr/lib/libLIBRARY.a. > > OK. > >>>>> BTW, Why there should be no traceback when relocatable libraries are >>>>> used? >> >> Traceback is always available, either in symbolic or numeric form. To >> get the symbolic form, you need the -dbg package installed. > > I meant g-trasym.adb. In Fedora's gcc 4.4 it is in the static library, but > absent in the shared. I don't understand why. Maybe the Fedora maintainers can explain? >>> Maybe, but other shared libraries can well be compiled with -g as well >>> as the application. But linking them with shared RTL fails if any of >>> them uses Traceback.Symbolic. >> >> That's because GNAT GPL includes a non-standard 'libaddr2line.a' >> produced from binutils (and therefore pure GPL) and calls that to >> produce the symbolic tracebacks. GCC (from the FSF) lacks this library. >> I patched GCC to use an alternate mechanism instead, i.e. fork()/exec() >> and call /usr/bin/addr2line. This restores the functionality in the FSF >> version of GNAT. > > Does it mean that under Debian g-trasym.adb is in both libraries? Yes. And they Just Work(tm) as they should :) -- Ludovic Brenta.
From: Dmitry A. Kazakov on 15 May 2010 03:46 On Fri, 14 May 2010 22:38:30 +0200, Ludovic Brenta wrote: > Dmitry A. Kazakov writes: >> On Fri, 14 May 2010 20:43:27 +0200, Ludovic Brenta wrote: >> >>>>>> BTW, Why there should be no traceback when relocatable libraries are >>>>>> used? >>> >>> Traceback is always available, either in symbolic or numeric form. To >>> get the symbolic form, you need the -dbg package installed. >> >> I meant g-trasym.adb. In Fedora's gcc 4.4 it is in the static library, but >> absent in the shared. I don't understand why. > > Maybe the Fedora maintainers can explain? From g-trasym.ads: "On all platforms except VMS, this package is not intended to be used within a shared library, symbolic tracebacks are only supported for the main executable and not for shared libraries. You should consider using gdb to obtain symbolic traceback in such cases." This reads to me: don't use in a shared library. Maybe they just followed this advice. I admit, I don't understand the text above. In particular, since any library is dead without the main executable, comparing them makes no sense to me. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Ludovic Brenta on 15 May 2010 06:07 Dmitry A. Kazakov writes on comp.lang.ada: > On Fri, 14 May 2010 22:38:30 +0200, Ludovic Brenta wrote: > >> Dmitry A. Kazakov writes: >>> On Fri, 14 May 2010 20:43:27 +0200, Ludovic Brenta wrote: >>> >>>>>>> BTW, Why there should be no traceback when relocatable libraries are >>>>>>> used? >>>> >>>> Traceback is always available, either in symbolic or numeric form. To >>>> get the symbolic form, you need the -dbg package installed. >>> >>> I meant g-trasym.adb. In Fedora's gcc 4.4 it is in the static library, but >>> absent in the shared. I don't understand why. >> >> Maybe the Fedora maintainers can explain? > > From g-trasym.ads: > > "On all platforms except VMS, this package is not intended to be used > within a shared library, symbolic tracebacks are only supported for the > main executable and not for shared libraries. You should consider using > gdb to obtain symbolic traceback in such cases." > > This reads to me: don't use in a shared library. Maybe they just followed > this advice. I admit, I don't understand the text above. In particular, > since any library is dead without the main executable, comparing them makes > no sense to me. To me this reads: do not call this from a shared library; however your main program can call this even if it is in a shared libgnat. There is no technical reason why g-trasym.adb cannot be compiled with -fPIC and included in a shared library. For that matter, if we followed your interpretation, g-trasym.adb should not be in a static library either. -- Ludovic Brenta.
From: Simon Wright on 15 May 2010 07:07 Ludovic Brenta <ludovic(a)ludovic-brenta.org> writes: > That's because GNAT GPL includes a non-standard 'libaddr2line.a' > produced from binutils (and therefore pure GPL) and calls that to > produce the symbolic tracebacks. GCC (from the FSF) lacks this > library. I patched GCC to use an alternate mechanism instead, > i.e. fork()/exec() and call /usr/bin/addr2line. This restores the > functionality in the FSF version of GNAT. Ludovic, could you point me towards the patch for this? On Mac OS X, we don't have addr2line, the equivalent is atos.
From: Ludovic Brenta on 15 May 2010 17:48 Simon Wright writes on comp.lang.ada: > Ludovic Brenta <ludovic(a)ludovic-brenta.org> writes: > >> That's because GNAT GPL includes a non-standard 'libaddr2line.a' >> produced from binutils (and therefore pure GPL) and calls that to >> produce the symbolic tracebacks. GCC (from the FSF) lacks this >> library. I patched GCC to use an alternate mechanism instead, >> i.e. fork()/exec() and call /usr/bin/addr2line. This restores the >> functionality in the FSF version of GNAT. > > Ludovic, could you point me towards the patch for this? On Mac OS X, we > don't have addr2line, the equivalent is atos. Latest version: http://green.ada-france.org:8081/revision/file/adfe332edf9057b6de622519fd9161421c5c9c76/debian/patches/ada-symbolic-tracebacks.diff HTH -- Ludovic Brenta.
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Trying to get A# set up (and failing) Next: AWS install problems |