Bug 2044028 - /usr/bin/ld: cannot open linker script file /builddir/build/BUILD/.package_note...: No such file or directory
Summary: /usr/bin/ld: cannot open linker script file /builddir/build/BUILD/.package_no...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: package-notes
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Zbigniew Jędrzejewski-Szmek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-01-23 08:12 UTC by marcindulak
Modified: 2022-02-06 15:20 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-02-06 15:20:34 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description marcindulak 2022-01-23 08:12:04 UTC
Description of problem:

This bug may be a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=2043178, however the symptoms look different.

The configure step of the ga package https://src.fedoraproject.org/rpms/ga fails when trying to create a test c program

```
/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
```

The above script seems indeed missing
```
...
+ ls -al /builddir/build/BUILD/
total 0
drwxrwxr-x. 3 mockbuild 1000  22 Jan 23 07:32 .
drwxrwxr-x. 9 mockbuild 1000 106 Jan 23 07:32 ..
drwxr-xr-x. 5 mockbuild mock  68 Jan 23 07:32 ga-5.7.2
...
```

Version-Release number of selected component (if applicable):

package-notes-srpm-macros-0.4-11.fc36

How reproducible:


Steps to Reproduce:
1. `koji build --nowait --scratch --arch-override x86_64 f36-rebuild` 

Actual results:

See the build.log at https://koji.fedoraproject.org/koji/taskinfo?taskID=81699099, pasted below

```
...
configure:4840: mpicc --version >&5
gcc (GCC) 12.0.1 20220118 (Red Hat 12.0.1-0)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:4851: $? = 0
configure:4840: mpicc -v >&5
mpicc for MPICH version 3.4.1
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-12.0.1-20220118/obj-x86_64-redhat-linux/isl-install --enable-offload-targets=nvptx-none --without-cuda-driver --enable-offload-defaulted --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux --with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220118 (Red Hat 12.0.1-0) (GCC) 
... rest of stderr output deleted ...
configure:4851: $? = 0
configure:4840: mpicc -V >&5
gcc: error: unrecognized command-line option '-V'
configure:4851: $? = 1
configure:4840: mpicc -qversion >&5
gcc: error: unrecognized command-line option '-qversion'; did you mean '--version'?
configure:4851: $? = 1
configure:4871: checking whether the C compiler works
configure:4893: mpicc  -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection  -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -Wl,-dT,/builddir/build/BUILD/.package_note-ga-5.7.2-8.fc36.x86_64.ld conftest.c -lscalapack -lflexiblas >&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
collect2: error: ld returned 1 exit status
configure:4897: $? = 1
configure:4935: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "Global Arrays (GA)"
| #define PACKAGE_TARNAME "ga"
| #define PACKAGE_VERSION "5.7.1"
| #define PACKAGE_STRING "Global Arrays (GA) 5.7.1"
| #define PACKAGE_BUGREPORT "hpctools"
| #define PACKAGE_URL "http://hpc.pnl.gov/globalarrays/"
| #define LINUX 1
| #define SYSV 1
| #define PACKAGE "ga"
| #define VERSION "5.7.1"
| #define MSG_COMMS_MPI 1
| #define ENABLE_PEIGS 0
| #define ENABLE_EISPACK 0
| #define ENABLE_PROFILING 0
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:4940: error: in `/builddir/build/BUILD/ga-5.7.2/ga-5.7.2-mpich':
configure:4942: error: C compiler cannot create executables
...
```


Additional info:

The error goes away by disabling package-note as suggested in https://bugzilla.redhat.com/show_bug.cgi?id=2043178#c24, with "%undefine _package_note_file"

Comment 2 marcindulak 2022-01-23 18:43:31 UTC
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

Comment 3 Zbigniew Jędrzejewski-Szmek 2022-01-23 21:18:56 UTC
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?

Comment 4 Vít Ondruch 2022-01-24 09:00:24 UTC
(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.

Comment 5 Zbigniew Jędrzejewski-Szmek 2022-01-24 09:09:05 UTC
> /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…

Comment 6 Zbigniew Jędrzejewski-Szmek 2022-01-24 10:06:12 UTC
(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

Comment 7 Vít Ondruch 2022-01-24 14:03:45 UTC
(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.

Comment 8 Todd Zullinger 2022-01-24 20:22:09 UTC
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.

Comment 9 Zbigniew Jędrzejewski-Szmek 2022-01-24 20:24:56 UTC
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/172

Comment 10 Zbigniew Jędrzejewski-Szmek 2022-01-24 20:32:12 UTC
> 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

Comment 11 Todd Zullinger 2022-01-24 20:52:37 UTC
(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.

Comment 12 Zbigniew Jędrzejewski-Szmek 2022-01-24 20:56:01 UTC
"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.

Comment 13 Todd Zullinger 2022-01-24 21:30:39 UTC
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.

Comment 14 Zbigniew Jędrzejewski-Szmek 2022-01-24 21:48:59 UTC
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.)

Comment 15 Todd Zullinger 2022-01-25 02:09:35 UTC
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!

Comment 16 Jerry James 2022-01-25 18:37:59 UTC
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.

Comment 17 Zbigniew Jędrzejewski-Szmek 2022-01-25 21:21:09 UTC
See the discussion starting at https://bugzilla.redhat.com/show_bug.cgi?id=2043092#c21

Comment 18 Fedora Update System 2022-02-06 15:16:48 UTC
FEDORA-2022-fc7bfc706f has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-fc7bfc706f

Comment 19 Fedora Update System 2022-02-06 15:20:34 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.