https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/82004
Summary:
The original discussion in https://reviews.llvm.org/D118493 was that
`clang` should not be adding `-rpath` implicitly for toolchains. The
main motivation behind that change was the 'Fedora' toolchain
disa
llvmbot wrote:
@llvm/pr-subscribers-clang
@llvm/pr-subscribers-clang-driver
Author: Joseph Huber (jhuber6)
Changes
Summary:
The original discussion in https://reviews.llvm.org/D118493 was that
`clang` should not be adding `-rpath` implicitly for toolchains. The
main motivation behind that
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/82004
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tstellar wrote:
I don't think a CMake option is the right way to go here. For example, I doubt
we would actually use this CMake option in Fedora if this patch is committed.
Does gcc use rpath for libgomp?
https://github.com/llvm/llvm-project/pull/82004
jhuber6 wrote:
> I don't think a CMake option is the right way to go here. For example, I
> doubt we would actually use this CMake option in Fedora if this patch is
> committed.
Does Fedora only use default configurations when building its packages?
> Does gcc use rpath for libgomp?
That's i
JonChesterfield wrote:
Enable by default without cmake and fedora run their own patch is my preferred
solution.
The Siemens dev working on gcc amdgpu offloading told me they set rpath on the
executable at a conference but I haven't checked their implementation. His
attitude was that programs
tstellar wrote:
> Does Fedora only use default configurations when building its packages?
We try to stick to the defaults as much as possible. Having an implicit rpath
by default causes issues when building other RPMs with clang, and typically, if
we need to change something in order to build
shiltian wrote:
IMHO I prefer to ask/request users to do the right thing. Vendors are totally
free to do whatever to be convenient for their customers via their compiler
wrappers/drivers, but for the community version, following the convention would
be good.
https://github.com/llvm/llvm-proje
jhuber6 wrote:
> > Does Fedora only use default configurations when building its packages?
>
> We try to stick to the defaults as much as possible. Having an implicit rpath
> by default causes issues when building other RPMs with clang, and typically,
> if we need to change something in order
tstellar wrote:
> We could make this logic more complicated by checking the system
> automatically `execute_command(lsb_release)` or something.
I think this is too complicated and fragile. If we want to do something
specifically to support the distro use case, I think we should do this:
http
jhuber6 wrote:
> > We could make this logic more complicated by checking the system
> > automatically `execute_command(lsb_release)` or something.
>
> I think this is too complicated and fragile. If we want to do something
> specifically to support the distro use case, I think we should do thi
tstellar wrote:
>
> I believe right now the `rtlib-rpath` points to the path
> `${CLANG_BINARY}../lib/${HOST_TRIPLE}/`. I think it's definitely reasonable
> to not put this on system libraries if that's a solution, since we can
> generally assume it's a global installation and already covered
jhuber6 wrote:
> > I believe right now the `rtlib-rpath` points to the path
> > `${CLANG_BINARY}../lib/${HOST_TRIPLE}/`. I think it's definitely reasonable
> > to not put this on system libraries if that's a solution, since we can
> > generally assume it's a global installation and already cov
tstellar wrote:
> > > I believe right now the `rtlib-rpath` points to the path
> > > `${CLANG_BINARY}../lib/${HOST_TRIPLE}/`. I think it's definitely
> > > reasonable to not put this on system libraries if that's a solution,
> > > since we can generally assume it's a global installation and al
JonChesterfield wrote:
> IMHO I prefer to ask/request users to do the right thing.
One of the drawbacks to asking users to do the "right thing" is that it goes
something like:
- you must use global state to tell the compiler where the compiler libraries
are
- you should do this using clang con
MaskRay wrote:
> The Fedora distributors were the only group that were against doing this by
> default, so the suggestion is that Fedora uses
> -DCLANG_ALLOW_IMPLICIT_RPATH=OFF when building.
I think other distributors and I are against this as well.
What this PR does can be achieved by addin
tstellar wrote:
Could we have the upstream default be to install a clang.cfg file in bin/ which
has -fimplicit-openmp-rpath (or whatever the hoption is)?
https://github.com/llvm/llvm-project/pull/82004
___
cfe-commits mailing list
cfe-commits@lists.
jhuber6 wrote:
> Could we have the upstream default be to install a clang.cfg file in bin/
> which has -fimplicit-openmp-rpath (or whatever the hoption is)?
Configuration files as far as I'm aware can't do toolchain / language specific
stuff, so it's a little weaker than being able to just res
jhuber6 wrote:
So, I'm wondering if we could do a clang configuration file based solution for
this. The problem that I see now is that we'd like to make some clang
configuration files only active for a certain language. I think we already have
OS specific files and target specific files, so it
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/82004
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
h-vetinari wrote:
What's the context for closing this?
https://github.com/llvm/llvm-project/pull/82004
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> What's the context for closing this?
Community did not want a new CMake config option and I wasn't planning on
moving forward with this, so I closed it to clean up my list of open PRs.
https://github.com/llvm/llvm-project/pull/82004
22 matches
Mail list logo
