On Wed, 06 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> I used to think of this as debug information, but I don't
> use -g, so it might be relocation and symbol table.
> It comes at the end of the file, it's about 500KB, and it
> can be removed with GNU strip (strip harbour.dll).
It's probably only symbol and relocation table.
Debug information is much bigger.
> Hm, I don't know, but I never see this GCC specific information
> at the end of any production Windows binary files, so I wonder
> why would we need it on harbour.dll only.
Debugging final application. F.e. you can see C call stack in debugger.
AFAIK GCC is the only one compiler we are using which does not reduce
the speed or change optimization methods when debug information is added.
This information intentionally internally separated, can be easy stripped
or even moved to separate files. F.e. when you create RPMs in Linux then
all debug information is moved to separated RPMs which you can install
when you want to see real C function names debugging your binaries or
tracing them with tools like valgrind.
In *nixes you have yet another important feature. You can set your
environment to generate core dump file with full application state
on GPF or similar error. Then it's enough to run gdb using this file
and you can see where and how your application crashed. For me debug and
relocation symbols are very important and of course if I want to create
final user binaries then I simply use strip in my build strips.
But for other C compilers it's not such easy because code after striping
is not the same as code generated without debug information though maybe
sth changed in last years here.
> Okay, new envvar is perfect.
> As for the non-GNU make system, make_gcc.sh could use it indeed.
What do you think about using the same envvar names in make_{vc,bcc}.bat?
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
