Liviu Ionescu

> I would accept a PR to add support for these additional values. I found an easier solution, I removed the dependency on 'arch' and reorganised my code.

`install_name_tool` allows to modify the rpath in the binary. I use a post-processing step to make all binaries relocatable.

I would not call it a 'big bug' yet; my build scripts are also doing some library re-arrangements, plus that the scripts should also work with other packages, which do...

I did a test and, after adding `-Wl,-headerpad_max_install_names` to the global LDFLAGS, the build script passed, so the ineffective HomeBrew trick is no longer needed. I'll restart the full build...

> c++tools (which provides g++-mapper-server) is not bootstrapped but built at the final stage. > So I'd not be surprised to see that BOOT_xxxxx does not apply Ok, so this...

> if one wants the libraries in a different place, one usually uses the slibdir/libdir config options... Yeah, just that this does not work for all libraries. When using custom...

> If the current @rpath compiler does not do this "out of the box" then please let me know - because it should do this just fine with no modification....

> Suppose you are a compiler user ... Nothing more should be needed Right, custom compiler, regular compile line; the elf runs, details are not relevant, user is happy, :-)...

> as described in the Developer Doc Oops, I read a few developer docs, but I missed the one with the recommended structure of `@rpath`. Do you remember what document...

> but neither makes a magic solution to the underlying issue - if you (re)move the dependent libs, then application is broken. I'm afraid this is a misunderstanding, the idea...