Page MenuHomeFreeBSD

devel/llvm*: Broken wrapper scripts when symlinking to them
ClosedPublic

Authored by tobik on Mar 18 2018, 7:39 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mar 2 2024, 9:01 PM
Unknown Object (File)
Jan 8 2024, 11:15 AM
Unknown Object (File)
Jan 8 2024, 11:15 AM
Unknown Object (File)
Jan 8 2024, 11:15 AM
Unknown Object (File)
Jan 8 2024, 11:15 AM
Unknown Object (File)
Dec 31 2023, 6:12 PM
Unknown Object (File)
Dec 29 2023, 7:28 AM
Unknown Object (File)
Dec 20 2023, 3:40 AM
Subscribers

Details

Summary

The llvm-wrapper scripts are broken when using them in symlinks. This is e.g. a problem in the ports tree when a port uses
BINARY_ALIAS=gcc=${CC} in combination with USES=compiler:c++14-lang on 10.3.

To reproduce the problem:

$ install -l rs /usr/local/bin/clang50 gcc
$ ./gcc
./gcc: /usr/local/llvm50/bin/gcc: not found

My expectation is that /usr/local/llvm50/bin/clang would be called as intended.

I suggest we put in a call to realpath to resolve symlinks before using basename to get the wrapper script name.

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 15630
Build 15665: arc lint + arc unit

Event Timeline

All of these are missing PORT_REVSION bumps.

devel/llvm60/files/llvm-wrapper.sh.in
8

This is wrong as the output of realpath is thrown away on the next line. It should probably be:

tool=$(/bin/realpath $0)
tool=${tool##*/}

The addition of /bin is necessary as neither realpath or basename are in PATH during installworld. If we're going to make everyone rebuild llvm for this change we should use the above version in all of them.

  • Add missing LLVM ports
  • Sync wrapper scripts
  • Bump PORTREVISIONs
  • Use /bin/realpath

The diff to llvm-devel is not unneeded, but the patch is otherwise ready to go.

This revision is now accepted and ready to land.Mar 26 2018, 10:36 PM
This revision was automatically updated to reflect the committed changes.

The diff to llvm-devel is not unneeded, but the patch is otherwise ready to go.

Thanks. I've landed this now because the recent switch to Perl 5.26 as default in rP465965 will cause rebuilds of all LLVM ports anyway.