Page MenuHomeFreeBSD

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

Authored by tobik on Mar 18 2018, 7:39 AM.

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
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

tobik created this revision.Mar 18 2018, 7:39 AM

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.

tobik updated this revision to Diff 40421.Mar 18 2018, 5:40 PM
  • Add missing LLVM ports
  • Sync wrapper scripts
  • Bump PORTREVISIONs
  • Use /bin/realpath
brooks accepted this revision.Mar 26 2018, 10:36 PM

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.
tobik added a comment.Mar 31 2018, 3:31 AM

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.