Bug 2044028
| Summary: | /usr/bin/ld: cannot open linker script file /builddir/build/BUILD/.package_note...: No such file or directory | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | marcindulak <Marcin.Dulak> |
| Component: | package-notes | Assignee: | Zbigniew Jędrzejewski-Szmek <zbyszek> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | loganjerry, tmz, trpost, vondruch, zbyszek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-02-06 15:20:34 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
marcindulak
2022-01-23 08:12:04 UTC
The discussion on devel is here https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DBPAQRE7IL3NHWQMVKSLPMKLP2OMWUJJ/ As suggested in the above devel thread, the "....package_note...: No such file or directory" error disappears when performing the build (configure/make) inside of the %build section of the spec. On the other hand one of the configure checks fails, but it seems not affecting the build: ``` ... checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ./configure: line 30012: -e 's/^T .* \(.*\)$/extern int \1();/p' -e 's/^[ABCDGIRSTW][ABCDGIRSTW]* .* \(.*\)$/extern char \1;/p': No such file or directory ... ``` See https://koji.fedoraproject.org/koji/taskinfo?taskID=81721382 for the logs. The "zdot wrong" test failure is something I'm hoping to go away after a rebuild of ga against the f36 rebuilt openblas https://src.fedoraproject.org/rpms/openblas/c/3ef1d5e9d5986ec3c032aa470276357c6f08dd56?branch=rawhide Yep, the package note file is created in the preamble of %build (and also %check with the latest redhat-rpm-config, but this doesn't matter here). The change to do configuration in %prep is right, it's more appropriate place for it, irrespectively of this issue. Is there anything else to fix here? (In reply to Zbigniew Jędrzejewski-Szmek from comment #3) > anything else to fix here? It would be nice if this problem was better detected/reported. > /usr/bin/ld: cannot open linker script file /builddir/build/BUILD/.package_note-ga-5.7.2-8.fc36.x86_64.ld: No such file or directory
I added a bunch of comments in redhat-rpm-config and package-notes that describe all the macros used.
Apart from slightly better docs I don't see how this could be detected and reported better. It's just
a file, and if you try to open it, you get the generic error that it doesn't exist…
(In reply to marcindulak from comment #2) > The "zdot wrong" test failure is something I'm hoping to go away after > a rebuild of ga against the f36 rebuilt openblas > https://src.fedoraproject.org/rpms/openblas/c/ > 3ef1d5e9d5986ec3c032aa470276357c6f08dd56?branch=rawhide It doesn't seem to help. I rebuilt ga with openblas-0.3.19-3.fc36.x86_64.rpm in mock, and it still fails with: > Checking zdot ... zdot wrong (86672.993582718176,915971.03870635165) (86672.994280842890,915971.06605762441) zdot wrong (86672.993582718176,915971.03870635165) (86672.994280842890,915971.06605762441) 0:... exiting:Received an Error in Communication application called MPI_Abort(comm=0x84000004, -1) - process 0 1:... exiting:Received an Error in Communication application called MPI_Abort(comm=0x84000002, -1) - process 1 (In reply to Zbigniew Jędrzejewski-Szmek from comment #5) > > /usr/bin/ld: cannot open linker script file /builddir/build/BUILD/.package_note-ga-5.7.2-8.fc36.x86_64.ld: No such file or directory > > I added a bunch of comments in redhat-rpm-config and package-notes that > describe all the macros used. > Apart from slightly better docs I don't see how this could be detected and > reported better. It's just > a file, and if you try to open it, you get the generic error that it doesn't > exist… This was specific case, triggered by call of `%configure` on some unexpected place. Since this ticket was reported, it should not be treated as unexpected anymore. So the `%configure` macro should make sure to either run only in `%build` section or possibly detect and warn missing package note file (suggesting to run `%configure` in `%build` section) prior it gets submitted to linker. The git package is affected by this as well. https://koji.fedoraproject.org/koji/taskinfo?taskID=81766455 is a scratch build which has package-notes-srpm-macros-0.4-13.fc36 in the build root and still exhibits the failure. I'll add `%undefine _package_note_file` to disable the package notes info and try to keep a watch on future developments. > I'll add `%undefine _package_note_file` to disable the package notes info and try to keep a watch on future developments.
Please just do following instead:
+# buildsubdir is not defined here, but only later, so fix _package_note_file not to use it.
+%global _package_note_file %{_builddir}/%{name}-%{pkgversion}/.package_note-%{name}-%{version}-%{release}.%{_arch}.ld
(In reply to Zbigniew Jędrzejewski-Szmek from comment #10) > Please just do following instead: > +# buildsubdir is not defined here, but only later, so fix _package_note_file not to use it. Sure, I'll give that a try. Can you tell me more about where "here" means in "buildsubdir is not defined here"? I'd rather not write a comment I can't explain to myself. :) Thanks Zbigniew. "here" means anywhere in %prep. I don't grok all the details, but %setup/%autosetup save the last unpacked directory and then before %build and %check and %install set %buildsubdir. Alright, that's close to what I was guessing, but it's good to know.
For some context, git doesn't use autoconf or a configure script. We write a config.mak in %prep which is included by the git Makefile. That config.mak includes `LDFLAGS = %build_ldflags`.
I do need to replace `%{pkgversion}` with `%{version}` in the _package_note_file definition, as the former macro is not defined.
I can see whether I can move the creation of config.mak to %build without much trouble. But initially, it seems to me that creating it in %prep is more appropriate. That allows someone to run %prep and cd to the build dir and run make to get the same results. That's admittedly not a common scenario and may well be broken and/or depend on other macros we use already. So it might be a better solution in the end to move it to %build.
I looked at git.spec (before writing comment #10), and I agree that it seems appropriate to generate config.mak in %prep. It shouldn't be necessary to move it, once the issue with %buildsubdir in %_package_note_file is resolved. (%{pkgversion} is not used anywhere, this seems to be some misunderstanding.) Thanks Zbigniew. I pushed the smaller change to set %_package_note_file and confirmed the .note.package contained "Packaging Metadata" field. The change in rawhide: https://src.fedoraproject.org/rpms/git/c/1dc07e7 The alternate change, to move config.mak creation to %build is here (for posterity): https://src.fedoraproject.org/fork/tmz/rpms/git/c/0731e3976?branch=package-note-alternate-fix I mentioned %pkgversion because that's what you wrote in comment #10. ;) Thanks again! Why not dispense with %buildsubdir entirely? That is, use this definition:
%_package_note_file %{_builddir}/.package_note-%{name}-%{version}-%{release}.%{_arch}.ld
That way, %{build_ldflags} will be the same in %prep and %build.
See the discussion starting at https://bugzilla.redhat.com/show_bug.cgi?id=2043092#c21 FEDORA-2022-fc7bfc706f has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-fc7bfc706f FEDORA-2022-fc7bfc706f has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report. |