We currently call /usr/lib/rpm/brp-strip-static-archive from %__os_install_post. This removes debugging symbols from static (.a) libraries.
Is this really a good idea? Due to this, glibc copies libc.a to glibc-debuginfo, so that you can get a link with debugging symbols by specifying “-static -L/usr/lib/debug/usr/lib64“ (potentially with unintended side effects). I would like to get this to work by default.
If developers does not want debugging symbols and static libraries have them, they can link with -s, or strip the linked object.
Thoughts?
I can file a Fedora 26 system-wide change for this if this warrants one.
Thanks, Florian
On 11/10/2016 12:16 PM, Florian Weimer wrote:
We currently call /usr/lib/rpm/brp-strip-static-archive from %__os_install_post. This removes debugging symbols from static (.a) libraries.
Is this really a good idea? Due to this, glibc copies libc.a to glibc-debuginfo, so that you can get a link with debugging symbols by specifying “-static -L/usr/lib/debug/usr/lib64“ (potentially with unintended side effects). I would like to get this to work by default.
If developers does not want debugging symbols and static libraries have them, they can link with -s, or strip the linked object.
Thoughts?
Having run into difficulty with debugging programs linked to static libraries before, I would like to see this fixed. It seems like a reasonable plan, but I don't have any technical knowledge here.
On Friday 11 November 2016 12:46 AM, Florian Weimer wrote:
We currently call /usr/lib/rpm/brp-strip-static-archive from %__os_install_post. This removes debugging symbols from static (.a) libraries.
Is this really a good idea? Due to this, glibc copies libc.a to glibc-debuginfo, so that you can get a link with debugging symbols by specifying “-static -L/usr/lib/debug/usr/lib64“ (potentially with unintended side effects). I would like to get this to work by default.
If developers does not want debugging symbols and static libraries have them, they can link with -s, or strip the linked object.
What happens if a program built without -g is linked to the libc.a with debug symbols? If it does the right thing by not including debug symbols then I think your suggestion is the right way forward. Otherwise we need to fix the linker to not include debug symbols first.
Siddhesh
On 11/14/2016 06:10 AM, Siddhesh Poyarekar wrote:
On Friday 11 November 2016 12:46 AM, Florian Weimer wrote:
We currently call /usr/lib/rpm/brp-strip-static-archive from %__os_install_post. This removes debugging symbols from static (.a) libraries.
Is this really a good idea? Due to this, glibc copies libc.a to glibc-debuginfo, so that you can get a link with debugging symbols by specifying “-static -L/usr/lib/debug/usr/lib64“ (potentially with unintended side effects). I would like to get this to work by default.
If developers does not want debugging symbols and static libraries have them, they can link with -s, or strip the linked object.
What happens if a program built without -g is linked to the libc.a with debug symbols? If it does the right thing by not including debug symbols then I think your suggestion is the right way forward.
By default, ld seems to include all available debugging information.
Do you suggest that gcc should invoke ld with -S, unless gcc was invoked with some -g flags or -s?
Otherwise we need to fix the linker to not include debug symbols first.
Is this really necessary? It's not the way ld currently works.
I think specifying -s if you want a binary without debugging information is an acceptable workaround.
Florian
On Monday 14 November 2016 02:18 PM, Florian Weimer wrote:
Do you suggest that gcc should invoke ld with -S, unless gcc was invoked with some -g flags or -s?
Ideal behaviour would be to make ld smarter about debuginfo but I don't know if that is doable, so this should do.
Otherwise we need to fix the linker to not include debug symbols first.
Is this really necessary? It's not the way ld currently works.
It is necessary because the idea of unexpectedly finding debuginfo in their binaries when one did not ask for it is counter-intuitive.
I think specifying -s if you want a binary without debugging information is an acceptable workaround.
It may be, but the default would be counter-intuitive.
Siddhesh
On Tue, 2016-11-15 at 10:57 +0530, Siddhesh Poyarekar wrote:
On Monday 14 November 2016 02:18 PM, Florian Weimer wrote:
Is this really necessary? It's not the way ld currently works.
It is necessary because the idea of unexpectedly finding debuginfo in their binaries when one did not ask for it is counter-intuitive.
I think this speaks more to a misunderstanding of the tools than unintuitive behaviour. -g is a compile phase option, and it asks for debugging info to be emitted for the object being compiled. It has no effect on the link phase. In your initial email you wrote:
What happens if a program built without -g is linked to the libc.a with debug symbols?
One does not build _programs_ with/out -g. One builds objects, and links objects into programs.
If your static binary is being built in an rpm then you will still end up with a stripped binary and separate debuginfo; it's just that now it will include debuginfo for the static library you linked against as well.
- ajax
On Tuesday 15 November 2016 08:03 PM, Adam Jackson wrote:
One does not build _programs_ with/out -g. One builds objects, and links objects into programs.
Sorry I did not word that correctly - I do know that emitting debuginfo is a compile time operation but I wanted to make the case that when linking objects, the linker should be aware of whether debuginfo was requested or not at compile time to maintain consistency about the presence of debuginfo in objects.
On thinking about this further though, the linker won't be able to do this automatically and it would need a hint from the compiler in some form or the other and I can't think of a sane way to do that, so I withdraw my objection. It would be nice however to make a note of this somewhere in the release notes.
Thanks, Siddhesh
-
Adam Jackson -
Florian Weimer -
Orion Poplawski -
Siddhesh Poyarekar