Bug 277036 - devel/libcircllhist: CTF not generated
Summary: devel/libcircllhist: CTF not generated
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Robert Clausecker
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-02-13 18:45 UTC by Ed Maste
Modified: 2024-03-02 20:55 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (fuz)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer freebsd_triage 2024-02-13 18:45:20 UTC
In the exp-run for fixing ctfmerge to return an error when it fails (PR276930) devel/libcircllhist is the one port that failed to build

- making CTF (circllhist.lo)
- compiling dcdflib.c
- making CTF (dcdflib.lo)
- compiling ipmpar.c
- making CTF (ipmpar.lo)
- linking libcircllhist.so.0.0.1
cc -shared -fstack-protector-strong  -Wl,-soname,libcircllhist.so.0 -O2 -pipe  -fstack-protector-strong -fno-strict-aliasing  -std=c99 -DCOMPAT_43TTY -I/usr/local/include -Wall -DNDEBUG -o libcircllhist.so.0.0.1 circllhist.lo dcdflib.lo ipmpar.lo -lm
- merging CTF (libcircllhist.so.0.0.1)
ERROR: ctfmerge: No ctf sections found to merge

circllhist.lo, dcdflib.lo, and ipmpar.lo are built without debugging (no -g), so ctfconvert does not emit any CTF sections, and ctfmerge's error is valid
Comment 1 Robert Clausecker freebsd_committer freebsd_triage 2024-02-13 20:49:24 UTC
This is quite a weird fix.  I expect the tool to just generate empty output when no CTF sections are present in the input.  Neverthless, I'll look into fixing this.
Comment 2 Ed Maste freebsd_committer freebsd_triage 2024-02-13 21:41:00 UTC
> This is quite a weird fix.

It seems weird to me to build without debugging information and then convert and merge non-existent debugging information. I agree that attempting to process an object without CTF data should not be an error for ctfmerge, but it is also just a pointless increase in build time and the CTF steps should just be skipped if this is being built without debugging.
Comment 3 Robert Clausecker freebsd_committer freebsd_triage 2024-02-13 21:52:09 UTC
(In reply to Ed Maste from comment #2)

That approach means the build system needs to know if debug information are being generated or not.  It often does not; flags to generate debug information may be passed in through CFLAGS or similar.  So unconditionally merging CTF information seems like a reasonable choice.

Checking on this, I found no clean solution as the build system does not have an obvious way to tell me if debug information are present.  I'll just ignore the exit status of ctfmerge for now.
Comment 4 Robert Clausecker freebsd_committer freebsd_triage 2024-02-13 21:52:10 UTC
(In reply to Ed Maste from comment #2)

That approach means the build system needs to know if debug information are being generated or not.  It often does not; flags to generate debug information may be passed in through CFLAGS or similar.  So unconditionally merging CTF information seems like a reasonable choice.

Checking on this, I found no clean solution as the build system does not have an obvious way to tell me if debug information are present.  I'll just ignore the exit status of ctfmerge for now.
Comment 5 Ed Maste freebsd_committer freebsd_triage 2024-02-14 14:42:48 UTC
> I'll just ignore the exit status of ctfmerge for now.

Yes, this seems like the best short-term change - explicitly ignore the exit status, rather than relying on ctfmerge implicitly ignoring what it wrongly considers an error.