hi!
That would be very long story...
JDK have feature of jlink. This can link a native image from only really needed subset of
jdk, and your applciation. To do this, it was using jmod files. which contained copy of
jdk "prepared" for jlinking.
The https://openjdk.org/jeps/493 allowed to do the same, with some constraints without jmods. Part of jlinking is to ensure, that you are really using what you should be, and thus binaries from jdk you jlink with, must be the binaries which
were built. You can easily imagine that stripping gebuginfo is immediately invalidating this. When distribution build hit it, Severin (now ccEd) attempted to bent it in usptream first, but that approach grow too complicated and out of its
scope so was rejected. Much better seemed to build jdk without interventions of rpm - including external debuginfo, and later reconstruct debuginfo and debugsources manually. Which worled exceptional fine in 4.20, but hit some old bugs on
4.1.x
Note, that fast and slowdebug subpackages/subjdks have intentionally debuginfo
nonstripped - both by jdk build, and by rpms, and thus this probelm is not
there.
Thanx for interest!
j.
On 6/3/25 11:14, Florian Weimer wrote:
* Jiri Vanek:
Hi Florian, thanx a lot for kind reply!
I saw the wrapper you have, and found it quite intensive. I was trying much
more simple workarounds, and also similar macro redefinition, but withotu
success.
I'm, not sure I need any redefinition at all. The only thing I know is
that rpm 4.1 is ignoring custom debuginfo pkg, but 4.20 is honoring
that. Seeing changelog of 4.20, it seemed that 4.20 addressed exactly
this, and that in 4.1x it was usually resolved by macros redefinition,
very often even on distribution level. Net search then popped out some
old threads of yours, where you were altering debuginfo macros - only
with different goals.
But why do you need to change debuginfo generation in the first place?
Thanks,
Florian
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
