Opened 21 months ago

Closed 21 months ago

Last modified 21 months ago

#65503 closed defect (fixed)

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

Reported by: cjones051073 (Chris Jones) Owned by:
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: kencu (Ken)
Port: libgcc12

Description

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 ?

Change History (10)

comment:1 Changed 21 months ago by kencu (Ken)

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

I’ll ask Iain to take a look.

comment:2 Changed 21 months ago by 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.

Last edited 21 months ago by kencu (Ken) (previous) (diff)

comment:3 Changed 21 months ago by 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...

comment:4 Changed 21 months ago by 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...

comment:5 Changed 21 months ago by Chris Jones <jonesc@…>

In c2f52d3529d4d8958143af466a32070fbfaec016/macports-ports (master):

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

comment:6 Changed 21 months ago by kencu (Ken)

Iain is looking into this.

comment:7 Changed 21 months ago by 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?

comment:8 Changed 21 months ago by 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.

comment:9 Changed 21 months ago by cjones051073 (Chris Jones)

Resolution: fixed
Status: newclosed

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

comment:10 in reply to:  6 Changed 21 months ago by 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 ?

Note: See TracTickets for help on using tickets.