Summary: | sys-devel/binutils: strip --strip-unneeded removes required debug info (breaking dev-lang/lazarus on amd64) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Gidea Liviu-Adrian <boshuboshu> |
Component: | [OLD] Development | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ferringb |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Requested fpc.cfg
New Project Archived forms.o |
Description
Gidea Liviu-Adrian
2009-05-10 08:44:16 UTC
Just in case this may be interest someone: 1)Directory for building test projects is set to /home/boshu/lazarustemp/ 2)Right click on the list in the messages window and select "Copy all messages to clipboard". Do that again and lazarus will crash. 3)Before upgrading to lazarus-0.9.2.26-r2 everything was fine: [ebuild U ] sys-devel/binutils-2.19.1-r1 [2.18-r3] USE="nls -multislot -multitarget -test -vanilla" 0 kB [ebuild U ] dev-lang/fpc-2.2.4 [2.2.2] USE="doc source" 81,031 kB [ebuild U ] dev-lang/lazarus-0.9.26-r2 [0.9.26] 0 kB (In reply to comment #1) > 2)Right click on the list in the messages window and select "Copy all messages > to clipboard". Do that again and lazarus will crash. Thanks, that looks like a big bug and it happens here too; I'll look into this. Unfortunately I cannot reproduce your first problem, at least on x86. Could you please attach your /etc/fpc.cfg, and if possible also your empty project's working directory (including object files)? Created attachment 191049 [details]
Requested fpc.cfg
The crash is a known bug upstream and happens with all clipboard copy operations. A fix was already available, which I've added to a new lazarus 0.9.26-r3 ebuild, and which will be in the tree shortly. Thanks for providing your fpc.cfg, but I don't see anything odd in it. Except for amd64 / x86 differences, your file is identical to mine, where the default project compiles and runs without problems. Were you able to get object files for a minimal (mostly empty) project displaying the bug? Created attachment 191174 [details]
New Project Archived
This is a new (empty) project saved in a folder. I've closed Lazarus, opened Lazarus, opened this project, tried to run it(ending with the same bug) then archived the directory.
(In reply to comment #0) > Actual Results: > unit1.o:(.debug_info+0xc2): undefined reference to `DBG2_FORMS_TFORM' > project1.lpr(17,1) Error: Error while linking > project1.lpr(17,1) Fatal: There were 1 errors compiling module, stopping I got same results on amd64. But i discovered that compilation is successfull goes sa if linking option -gl is disabled in Project->Compiler parameters. (In reply to comment #6) > (In reply to comment #0) > > Actual Results: > > unit1.o:(.debug_info+0xc2): undefined reference to `DBG2_FORMS_TFORM' > > project1.lpr(17,1) Error: Error while linking > > project1.lpr(17,1) Fatal: There were 1 errors compiling module, stopping > > I got same results on amd64. > But i discovered that compilation is successfull goes sa if linking option -gl > is disabled in Project->Compiler parameters. > I confirm that upon disabling "(In reply to comment #6) > (In reply to comment #0) > > Actual Results: > > unit1.o:(.debug_info+0xc2): undefined reference to `DBG2_FORMS_TFORM' > > project1.lpr(17,1) Error: Error while linking > > project1.lpr(17,1) Fatal: There were 1 errors compiling module, stopping > > I got same results on amd64. > But i discovered that compilation is successfull goes sa if linking option -gl > is disabled in Project->Compiler parameters. > I confirm that disabling "Display Line Numbers in Run-time Error Backtraces (-gl)" in the "Linking" tab, gives a different message when running(F9): "project 'project1' successfully built. :)" Still the project doesn't run. The caption of the lazarus window shows the "(debugging...)" text but the window of the project doesn't show. Closing lazarus, entering the directory of the saved project i see the new executable file. Running the file shows the empty form meaning that indeed the project has been successfully build :). Still this is an annoying work-around. This looks like another example of strip --strip-unneeded causing problems with fpc. vapier: I'll attach forms.o as generated by lazarus. When passed to strip, the debug info is removed, but when other units (even those not yet compiled) are compiled, the result may contain references to that debug info, so it needs to be kept. Created attachment 191461 [details]
forms.o
--strip-unneeded is supposed to remove debug info. if lazarus actually needs it, then .o files shouldnt be stripped at all. −−strip−unneeded Remove all symbols that are not needed for relocation processing. Normally, this means all debugging symbols can be removed, but it looks like fpc-generated object files are an exception. It would be reasonable to expect --strip-debug to nuke them, but is it really right that --strip-unneeded does so as well? Anyway, I'm not opposed to making the ebuild (for fpc as well as lazarus) exclude *.o from stripping. If you're sure binutils is doing the right thing, then fpc/lazarus simply need it, and I'll update the ebuilds to do so. i'm pretty sure binutils is (finally) doing the right thing, but i'll double check with upstream It's been a while and i don't expect this bug to be closed soon. I think it would be better if we would consider readding to the portage tree the last known working on amd64 version. The last one was: [ebuild U ] sys-devel/binutils-2.19.1-r1 [2.18-r3] USE="nls -multislot -multitarget -test -vanilla" 0 kB [ebuild U ] dev-lang/fpc-2.2.4 [2.2.2] USE="doc source" 81,031 kB [ebuild U ] dev-lang/lazarus-0.9.26-r2 [0.9.26] 0 kB The current version is unusable as nowadays you can't program anything without debugging and installing packages. What is your opinion? vapier, did you get anything from upstream yet? Anyway, I decided to check to see how many packages actually install .o files on my system. $ grep -c '\.o ' /var/db/pkg/*/*/CONTENTS | grep -v :0 /var/db/pkg/dev-lang/fpc-2.2.4-r1/CONTENTS:598 /var/db/pkg/dev-lang/gpc-20070904/CONTENTS:5 /var/db/pkg/dev-lang/lazarus-0.9.26-r3/CONTENTS:490 /var/db/pkg/dev-lang/python-2.6.2-r1/CONTENTS:1 /var/db/pkg/dev-lang/sunstudioexpress-2009.03/CONTENTS:41 /var/db/pkg/sys-devel/gcc-2.95.3-r10/CONTENTS:4 /var/db/pkg/sys-devel/gcc-3.3.6-r1/CONTENTS:5 /var/db/pkg/sys-devel/gcc-3.4.6-r2/CONTENTS:5 /var/db/pkg/sys-devel/gcc-4.0.4/CONTENTS:5 /var/db/pkg/sys-devel/gcc-4.1.2/CONTENTS:6 /var/db/pkg/sys-devel/gcc-4.2.4-r1/CONTENTS:6 /var/db/pkg/sys-devel/gcc-4.3.3-r2/CONTENTS:20 /var/db/pkg/sys-devel/gcc-4.4.0/CONTENTS:18 /var/db/pkg/sys-devel/nwcc-0.7.6/CONTENTS:3 /var/db/pkg/sys-libs/glibc-2.10.1/CONTENTS:12 Are there other packages that install so many .o files? The stripping of .o files doesn't seem to affect anything nearly as greatly as fpc/lazarus, and it's caused many problems... I'm not saying it should be turned off, but if it could be made any safer, please. RESTRICT=strip re-added for now. can this be closed? |