Ludovic Brenta wrote:
Kevin Brown [EMAIL PROTECTED] writes:
[...]
So I'm tempted to file another bug, this one against libgnat-4.1,
stating that we need to compile a debug version (that would land in
/usr/lib/debug) so that it's possible to set breakpoints within
library functions. We
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/adalib/libgnarl.a
and I really don't think you need libpython2.4.a or anything else.
The reason why you need static Ada libraries and nothing else is
because all Ada libraries are linked dynamically against
libgnat-4.1.so; if you replace it with a static
Ludovic Brenta wrote:
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/adalib/libgnarl.a
and I really don't think you need libpython2.4.a or anything else.
The reason why you need static Ada libraries and nothing else is
because all Ada libraries are linked dynamically against
libgnat-4.1.so; if you replace
Kevin Brown wrote:
We explicitly add -lpython2.4 at the end of the linker section.
libgps.a depends on python so we have to link against it. So in order
to link the application with -static.
Heh. Nice, complete sentence of mine there. :-)
It should read: So in order to link the
Kevin Brown writes:
[Trouble linking statically]
For what it's worth, here's one iteration of the linker package
definition that I've tried to use:
package Linker is
for Default_Switches (Ada) use
(-g,
-static,
/usr/lib/libgnatprj.a,
Ludovic Brenta wrote:
The problems are:
- You must pass -static to the *binder*, not the *linker*. As per the
GAT documentation, you do not need to pass libgnata or libgnarl.a
explicitly; the binder's job is to figure out these things for you.
A.*now* I understand.
This is what
I wrote:
My next experiment is to put both File_Array and Virtual_File into the
same storage pool and see what happens with that.
I not only did that, I also put Contents_Access into that same storage
pool (Contents_Access is the value associated with a Virtual_File, which
in turn is used
Kevin Brown [EMAIL PROTECTED] writes:
I modified the Contents_Access finalization code to configure the
debug pool to not raise exceptions and instead to print out the
various information it can when encountering this error. The end
result looks like this:
Be careful: Virtual_File is
Ludovic Brenta wrote:
Kevin Brown [EMAIL PROTECTED] writes:
I modified the Contents_Access finalization code to configure the
debug pool to not raise exceptions and instead to print out the
various information it can when encountering this error. The end
result looks like this:
Be careful:
Kevin Brown writes:
All I wanted to do was to call GNAT.Debug_Pool.Configure().
Ideally, I'd want to call it only once at program initialization
time, but I don't know how to do that from within vfs.adb, so I
settled on calling it from the finalization code.
You can add elaboration code like
Ludovic Brenta wrote:
So I'm tempted to file another bug, this one against libgnat-4.1,
stating that we need to compile a debug version (that would land in
/usr/lib/debug) so that it's possible to set breakpoints within
library functions. We should do so for the various libgtkada-2.8
libraries
Kevin Brown [EMAIL PROTECTED] writes:
I can't just specify -static because it requires *all* libraries to
be static.
All Ada libraries only, i.e. not glibc or GTK+. The Ada libraries
involved are:
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/adalib/libgnat.a
/usr/lib/libgnatprj.a
/usr/lib/libgnatvsn.a
Ludovic Brenta wrote:
Kevin Brown [EMAIL PROTECTED] writes:
I can't just specify -static because it requires *all* libraries to
be static.
All Ada libraries only, i.e. not glibc or GTK+. The Ada libraries
involved are:
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/adalib/libgnat.a
Ludovic Brenta wrote:
Valgrind flagged directory_tree.adb:1161 as deallocating memory that
was already freed. Removing that one line didn't solve the problem,
though; I had to change _all_ calls to VFS.Unchecked_Free into no-ops
before the symptoms (crashes) disappeared. So, yes, we do need
Kevin Brown wrote:
Hmm...for this we might be able to limit ourselves to one type to start
with, presumably whatever the root for File_Array_Access happens to be.
I don't know what that type is offhand, and am not really sure where to
look to find out (remember, I'm new to this). I expect
I wrote:
This raises a question, though: where in the *world* is Virtual_File
*actually defined*? In vfs.ads it's merely declared as private, but
vfs.adb doesn't seem to define it at all! How can it possibly actually
be used within vfs.adb when it's not even defined??? It doesn't seem to
Ludovic Brenta wrote:
Running gnat-gps under valgrind revealed many, many errors. One
seemed related to #400876 and #400883, which I was investigating at
the time; it looked like a double deallocation problem:
==25342== Address 0x9F3D820 is 48 bytes inside a block of size 840 free'd
Kevin Brown writes:
Why are we using any unchecked deallocations at all? That seems
counter to one of the biggest reasons to use Ada: correctness
checking.
I'd rather take the potential heap usage hit and guarantee
correctness here. Is there any way we can turn this uncheck
deallocation
Package: gnat-gps
Version: 4.0.1-2
Severity: important
Steps to reproduce:
$ rm -rf ~/.gps
$ gnat-gps
The welcome screen appears, giving options to (1) Start with a
default project in directory, (2) Create new project with wizard,
or (3) Open existing project. Select (1) or (3), then click on
Running gnat-gps under valgrind revealed many, many errors. One
seemed related to #400876 and #400883, which I was investigating at
the time; it looked like a double deallocation problem:
==25342== Address 0x9F3D820 is 48 bytes inside a block of size 840 free'd
==25342==at 0x4A1B46D: free
20 matches
Mail list logo
