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)
Mon, Dec 9, 1:47 PM
Unknown Object (File)
Fri, Nov 22, 10:24 PM
Unknown Object (File)
Fri, Nov 22, 4:58 PM
Unknown Object (File)
Nov 22 2024, 12:20 PM
Unknown Object (File)
Nov 21 2024, 4:24 PM
Unknown Object (File)
Nov 19 2024, 11:55 PM
Unknown Object (File)
Nov 19 2024, 1:09 PM
Unknown Object (File)
Nov 15 2024, 1:36 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
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

All of these are missing PORT_REVSION bumps.

devel/llvm60/files/llvm-wrapper.sh.in
8 ↗(On Diff #40401)

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.