|
Bugzilla – Full Text Bug Listing |
| Summary: | jfsutils fails with -fno-common | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Martin Liška <martin.liska> |
| Component: | Basesystem | Assignee: | Martin Liška <martin.liska> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | alynx.zhou, dimstar, michal.hrusecky, ohering, per |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | |||
| Bug Blocks: | 1160244 | ||
|
Description
Martin Liška
2020-01-07 13:55:54 UTC
Assigning to ldewey: libguestfs is the only consumer of jfsutils and with the original maintainer of that package having left SUSE, it would make sense to move this tool under the same maintainership (CCed the other two maintainers of libguestfs) Given /proc/config.gz:CONFIG_JFS_FS=m, we should probably wade through the compiler errors and warnings of jfsutils and see what can be fixed. Larry, do you have resources to fix and maintain this pkg? Olaf, I should be able to take this on along side my other responsibilities. The problems seems to lie with re-using variable names, which `-fno-common` strictly prohibits. I have created a patch in home:ldewey:branches:filesystem/jfsutils which seems to fix the errors encountered when passing that build flag. It would be beneficial to have this regression tested, though. (In reply to Larry Dewey from comment #4) > Olaf, I should be able to take this on along side my other responsibilities. > The problems seems to lie with re-using variable names, which `-fno-common` > strictly prohibits. I have created a patch in > home:ldewey:branches:filesystem/jfsutils which seems to fix the errors > encountered when passing that build flag. It would be beneficial to have > this regression tested, though. Hm, looks the last release happened 9 years ago. Thus, it probably does not make sense to report to upstream. Right? Although I don't know the significance of that build-flag, I think it would be beneficial to report it upstream. While I agree any work pushed back upstream is beneficial for everyone, OBS has additional patches from quite a while ago which have not made it upstream, either. While I am unsure of the creators rationale for those patches not being submitted, I know the current release of the upstream code doesn't even compile without them. My guess is the upstream project isn't currently maintained. Submit Request for filesystem/jfsutils: https://build.opensuse.org/request/show/762578 Build was merged into jfsutils. There's another issue: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:N/jfsutils/standard/x86_64 [ 50s] /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld: extract.o (symbol from plugin): in function `xchklog_final_processing': [ 50s] (.text+0x0): multiple definition of `xchklog_buffer'; display.o (symbol from plugin):(.text+0x0): first defined here [ 50s] In function 'strncpy', [ 50s] inlined from 'parse_parms' at fscklog.c:205:5, [ 50s] inlined from 'main' at fscklog.c:140:7: [ 50s] /usr/include/bits/string_fortified.h:106:10: warning: '__builtin___strncpy_chk' specified bound depends on the length of the source argument [-Wstringop-overflow=] [ 50s] 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); [ 50s] | ^ [ 50s] fscklog.c: In function 'main': [ 50s] fscklog.c:198:14: note: length computed here [ 50s] 198 | arg_len = strlen(optarg); [ 50s] | ^ [ 50s] collect2: error: ld returned 1 exit status I've made a SR#798382. Fixed in devel project. |