rpath argument change in GCC / LD

[Chris Jones]

Hi,

If the port is using the as version from cctools, then the logic behind 
what liker is used under the hood is the following

1. *If* the clang version consistent with the llvm version the cctools 
was build with is installed when the linker is run, then this will be 
used. Note this does vary with OSX version (see the cctools portfile).

2. Failing that, the linker is now told to use /usr/bin/as instead, 
which thus defers to the Xcode clang that is installed.

3. If that fails, the previous ancient gnu as version shipped with 
cctools (which increasingly has problems with things like AVX etc., 
hence the recent changes) is used.

So yes, there is variations in the versions used between OSX versions. 
There are also variations depending on what happens to be installed at 
build time. This is because cctools cannot directly depend on any clang 
version, for reasons of circular dependencies. Hence the 'use it if it 
is there' logic in 1.

If you are not sure what cctools is doing on some specific machine, just 
run 'as -v' making sure that is using MP's cctools as (e.g. 
/opt/local/bin/as).

See

https://github.com/macports/macports-ports/pull/3486

for more details.

One thing that is currently not done, but perhaps could be added, is the 
ability (via an env var or something) to disable 1 and/or 2 above, so 
revert back to effectively what was done before, to always use the 
ancient gas linker. I am not sure this is really needed though, more 
likely you just need to tweak your linker flags to something that works 
with the more up to date clang's now being used.

Chris

On 04/02/2019 3:23 pm, Michael Dickens wrote:
> So from your list below as I've labeled them, only (3) works in my testing with GCC8 as the pass-through compiler between the SciPy script creating this code & the linker. I have not tested any other GCC version, but I'm guessing it's the linker that's called that determines whether the -rpath flag usage is valid. As I said: This is a fairly recent change in the linker, which I'm guessing has something to do with which linker is being used: MP's or Xcode's. All of my testing over the weekend was on 10.14, which passes the link command through to Xcode's linker. I will try testing on my older OSX boxes to see what happens there, since I'm guessing they use MP's linker (as Xcode's is so old). If (3) works on all of the linkers, then I'll go with it (patching to include the ""s). - MLD
> 
> On Mon, Feb 4, 2019, at 12:22 AM, Ken Cunningham wrote:
>> My understanding is that this should not work:
>>
> (1) > -Wl,-rpath=“DIR”
>>
>> But these two are functionally the same, assuming they are not reordered.
>>
> (2) > -Wl,-rpath -Wl,”DIR”
>>
>> or
>>
> (3) > -Wl,-rpath,”DIR”
>>
>> Both are sent to the linker as two options sequentially:
>>
>> -rpath “DIR”
>>
>> Ken