libgcc12: libgcc_s.1.dylib is missing its @rpath entry

[cjones051073 (Chris Jones)]

Leads to issues such as one recently posted on the user list, where following the update all previously OK binaries where failing to run with

dyld: Library not loaded: @rpath/libgcc_s.1.1.dylib
Referenced from: /opt/local/lib/libgcc/libgcc_s.1.dylib
Reason: image not found
Trace/BPT trap

Recompiling the code fixed things, but what I think is odd is the fact /opt/local/lib/libgcc/libgcc_s.1.dylib does not have an RPATH entry

Oberon /opt/local/lib/libgcc > otool -l libgcc_s.1.1.dylib | grep -A 3 RPATH 
Oberon /opt/local/lib/libgcc >

compared to other dylib in libgcc12

/opt/local/lib/libgcc > otool -l libgfortran.5.dylib | grep -A 3 RPATH  
          cmd LC_RPATH
      cmdsize 32
         path @loader_path/ (offset 12)
Load command 16
          cmd LC_RPATH
      cmdsize 40
         path /opt/local/lib/libgcc (offset 12)
Load command 17
          cmd LC_RPATH
      cmdsize 32
         path @loader_path (offset 12)
Load command 18
          cmd LC_RPATH
      cmdsize 120
         path /opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc12/libgcc12/work/build/gcc (offset 12)
Load command 19
          cmd LC_RPATH
      cmdsize 32
         path /opt/local/lib (offset 12)

In particular, given we build gcc with the option

 --with-darwin-extra-rpath=${prefix}/lib/libgcc

I would at least expect to see that there ?

Ken - thoughts ? Can you check with Iain as to if this is a bug or not ?

[kencu (Ken)]

I agree… somehow that dylib is missing it’s rpath entry.

I’ll ask Iain to take a look.

[kencu (Ken)]

even for the one that has it, those rpath entries look kinda messed up…

if it looks first in /opt/local/lib/libgcc for other dylibs, then in the build directory, the whole point of the rpath change would seem to have been defeated…

I’ll look at mine and see what gives here. If the build directory is listed in the final installed dylib, it should at least be first. I wouldn’t have thought it should be there at all post-install.

[cjones051073 (Chris Jones)]

Thanks. I have a work around ready I am just testing now to manually add the missing rpath entry. Which can then be removed if it gets fixed upstream...

[cjones051073 (Chris Jones)]

p.s. on the 'build area' rpath I also noted that... I agree it would be best to remove it at the end of the build if its just there for the internal gcc testing...

[Chris Jones <jonesc@…>]

In c2f52d3529d4d8958143af466a32070fbfaec016/macports-ports (master):

gcc1{0,1,2}: Add work around for missing rpath entries
See: #65503

[kencu (Ken)]

Iain is looking into this.

[kakuhen]

I'm posting here to note this broke emacs-app on my end. A full recompilation of affected ports indeed fixed the linker errors. Maybe in the meantime it may be useful to revbump ports depending on libgcc? Though that seems like an awful lot of work compared to the patch made by cjones.

A user on IRC was also reporting issues with R and libgfortran not appearing in the @rpath. Could that be related to this issue?

[kencu (Ken)]

Many ports may need to be revbumped to pick up the added rpath search directory to ${prefix}/lib/libgcc.

But for now, installing the newly tweaked libgcc12 (11,10) is step 1, and should fix at least some of them.

Whatever is still broken after that will need revbumping to get the rpath embedded in the executables.

[cjones051073 (Chris Jones)]

Closing this as the above commits fix the specific issue here. New tickets should be submitted for any additional rpath related issues.

[cjones051073 (Chris Jones)]

Replying to kencu:

Iain is looking into this.

Did you also raise the issue of the rogue build-area rpaths with him ? I think these should be stripped once the testing is over, before the final installation ?