strip works on the second time

[stsp]

__gcc_bcmp.o.gz

strip works in some strange way. Attached is a test object file. Running i586-pc-msdosdjgpp-strip __gcc_bcmp.o for the first time, reduces the size from 7757 to 7043, and all debug sections are still there. Running strip the second time works, reducing the size to 330 bytes. Tried on binutils-2.35 which probably already have your coff patches. Same on 2.32.

[jwt27]

That's interesting. The first pass removes the symbol table and relocations (which already makes the file unsuitable for linking, so I don't know why you would want to do that). The second pass then removes the debug sections.

For some reason the DEBUGGING flag is missing from debug sections in the file you have there, but it magically appears after the first strip. When I compile some files myself, these sections have the correct flag, so I can't replicate this.

[stsp]

Well, this happens for some reason on an opensuse build which I try to deploy: https://build.opensuse.org/build/home:stsp2/openSUSE_Tumbleweed/i586/build-gcc/_log https://build.opensuse.org/package/binaries/home:stsp2/build-gcc/openSUSE_Tumbleweed One URL is a build log, another one are the built binaries. There is something wrong with the build of libgcc.a... Which is that the debug sections have the ALLOC flag and no DEBUGGING flag. The same source works on other build servers, so I am a bit confused.

[jwt27]

I can't access the log file. Could you post it to gist or pastebin?

[stsp]

_log.txt.gz

Sure enough, I posted it here. Thanks!

[stsp]

I am guessing that the problem is somewhere in a stage1 xgcc. Because when I try the same commands locally (with stage2 gcc), I can't build such a strange binary.

[stsp]

I wonder why do we use --enable-lto. Looks suspecious.

[stsp]

No, disabling plugins didn't help in this case. Trying with disabling lto...

[stsp]

Nothing helps. Here is the new log. _log.gz

I wonder why the lib gets not stripped here, and is stripped on COPR. Perhaps in the log we need to look for some problems with strip.

[stsp]

build.log.gz

Here is the copr log from "good" build, for comparison.

[jwt27]

LTO shouldn't be a problem unless you have -flto in CFLAGS_FOR_TARGET. I'm not sure how complete the LTO implementation is for djgpp, but enabling it doesn't hurt.

The only error message I see in the log file is this:

[ 1815s] build-gcc.x86_64: E: files-duplicated-waste (Badness: 100) 4649082
[ 1815s] Your package contains duplicated files that are not hard- or symlinks. You
[ 1815s] should use the %fdupes macro to link the files to one.
[ 1815s] 
[ 1815s] 2 packages and 0 specfiles checked; 1 errors, 38 warnings.

Seems you're generating 4.6 million duplicated files somehow.

[stsp]

There is no error. The package builds. You can get it from here: https://build.opensuse.org/package/binary/download/home:stsp2/build-gcc/openSUSE_Tumbleweed/x86_64/build-gcc-1620565415.dfc949a-6.1.x86_64.rpm

Once you get it, you can extract libgcc.a from it. Or if you don't want to, here it is attached: libgcc.a.gz Its not stripped, and it has wrong flags on a debug sections.

[stsp]

By disabling LTO and fat, the rpm archive shrink by 7Mb.

[jwt27]

Okay sorry, I thought the issue was that the build failed because of this.

I'd say COPR is in the wrong here, those libraries should not be stripped. This appears to be done as part of rpmbuild: https://github.com/rpm-software-management/rpm/blob/master/scripts/brp-strip-static-archive What I find surprising is that it uses /usr/bin/strip, which is somehow capable of reading coff-go32 files. Most likely it's misinterpreting them as pe-coff, that could cause trouble.

As for the SUSE build, I see you're using the binutils source package from djgpp ftp. This has some duplicated code now (old patches applied over new ones) so I suspect that could cause it. Try using binutils from GNU ftp.

[stsp]

This has some duplicated code now (old patches applied over new ones) so I suspect that could cause it.

The same problem happened with binutils-2.32 (also from djgpp site), so at least I can be sure its not a binutils problem (at least not a recent one). Unfortunately "try this and that" takes a few hours, as the build is very long. So while I'd like to polish things up eventually, for now I'll refrain from changing binutils.

Well, you are an absolute genius to find this thing about brp-strip-static-archive. Indeed, the host strip tool strips libgcc quite fine, making it functional again! I checked locally and I find that when not packaging rpm, the lib is indeed not stripped. But it is nevertheless correctly built. So the next step should be to avoid stripping in rpm, and then see if things broke or not.

[stsp]

And I can't experiment locally until this is fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1958566 Breaking the package management software is not the best thing to do for a distro.

[stsp]

Yes, brp was the problem. You are cool. :) Thanks!

[jwt27]

Ah, so SUSE was also trying to strip the libraries, I didn't see that at first. Strange then how it had different effects on both platforms. Clearly they were being misidentified as some other COFF variant (likely PE). Anyway, glad to hear you got it to work!

[stsp]

Probably different effect can be explained by the different binutils? Probably not, as OBS has 2.36 and fedora rawhide has 2.36. While other fedora builds have 2.34 or 2.35, I was testing the rawhide version, which should match obs rather closely...