Re: rpath argument change in GCC / LD

Ken and I are discussing off-list too :) gfortran is interpreting the '-Wl,-rpath' flag provided to it. In our testing both "-Wl,-rpath,PATH" and "-Wl,-rpath -Wl,PATH" work, but "-Wl,-rpath=PATH" does not work. Doesn't seem to matter if PATH or "PATH" (quoted or not). It could be that gfortran8

Re: rpath argument change in GCC / LD

Hi, Hmmm, quite right. Then perhaps what you are now seeing are the changes That is from July last year though - There have been no significant changes since then

Re: rpath argument change in GCC / LD

> If the port is using the as version from cctools Hey, Chris — all that applies to the assembler, but Michael is trying to beat the linker into submission. K

Re: rpath argument change in GCC / LD

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 var

Re: rpath argument change in GCC / LD

For scipy etc, I imagine it would be more likely what the python build script does with it than what the linker driver does with it that might cause trouble. Some of these build systems, esp these “simple" python script build systems, do funky business. But if you pass those commands directly t

Re: rpath argument change in GCC / LD

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 f

Re: rpath argument change in GCC / LD

My understanding is that this should not work: -Wl,-rpath=“DIR” But these two are functionally the same, assuming they are not reordered. -Wl,-rpath -Wl,”DIR” or -Wl,-rpath,”DIR” Both are sent to the linker as two options sequentially: -rpath “DIR” Ken

rpath argument change in GCC / LD?

I'm trying to update NumPy to 1.61.1, with some success ... but have come up with something odd with respect to the distutils/fcompiler/gnu.py provided within NumPy: the "rpath" setting that I fixed a little over 2 years ago has reared its ugly head! The original code at the time was (NumPy 1.1