* Default rpaths in BUILD_LDFLAGS
@ 2017-03-08 0:43 Martin Kelly
2017-03-08 21:46 ` Khem Raj
0 siblings, 1 reply; 7+ messages in thread
From: Martin Kelly @ 2017-03-08 0:43 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Enrico Scholz
Hi,
While debugging an issue with a package that uses llvm-config to compile
with clang, I started hitting [rpaths] QA warnings because some output
executables contained absolute rpaths pointing into my build directory.
After tracing through the issue, I determined the rpaths to eventually
be originating from the setting of BUILD_LDFLAGS in
meta/conf/bitbake.conf. The rpath part of this was added in commit
35759f97 to the poky repo.
A quick grep through the poky repo reveals that many projects have
turned off rpath in their builds (the mechanism through which is
build-system-dependent and doesn't always work right). Obviously, I can
do the same for clang/llvm-config, but it doesn't seem like the ideal
solution if many projects are having to do the same.
I'm wondering if those with more background on this issue could provide
more detail regarding why rpaths are set at the top level and why they
are necessary. In addition, I'm wondering if there might be a cleaner
way to remove the rpaths for those projects that need to do so without
each project manually writing sed and similar invocations to do it.
Thanks,
Martin
In case you're curious about the background of the issue, my project is
using the output of llvm-config --ldflags to set its linker flags.
llvm-config is populating the output --ldflags with whatever it is given
for CXX_LINK_FLAGS. CXX_LINK_FLAGS is being populated by the generic
cmake logic in cmake.bbclass, which is getting its flags from
BUILD_LDFLAGS in meta/conf/bitbake.conf.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Default rpaths in BUILD_LDFLAGS
2017-03-08 0:43 Default rpaths in BUILD_LDFLAGS Martin Kelly
@ 2017-03-08 21:46 ` Khem Raj
2017-03-08 21:56 ` Martin Kelly
0 siblings, 1 reply; 7+ messages in thread
From: Khem Raj @ 2017-03-08 21:46 UTC (permalink / raw)
To: Martin Kelly
Cc: Enrico Scholz, Patches and discussions about the oe-core layer
On 17-03-07 16:43:47, Martin Kelly wrote:
> Hi,
>
> While debugging an issue with a package that uses llvm-config to compile
> with clang, I started hitting [rpaths] QA warnings because some output
> executables contained absolute rpaths pointing into my build directory.
> After tracing through the issue, I determined the rpaths to eventually be
> originating from the setting of BUILD_LDFLAGS in meta/conf/bitbake.conf. The
> rpath part of this was added in commit 35759f97 to the poky repo.
thats for native packages alone.
>
> A quick grep through the poky repo reveals that many projects have turned
> off rpath in their builds (the mechanism through which is
> build-system-dependent and doesn't always work right). Obviously, I can do
> the same for clang/llvm-config, but it doesn't seem like the ideal solution
> if many projects are having to do the same.
>
> I'm wondering if those with more background on this issue could provide more
> detail regarding why rpaths are set at the top level and why they are
> necessary. In addition, I'm wondering if there might be a cleaner way to
> remove the rpaths for those projects that need to do so without each project
> manually writing sed and similar invocations to do it.
>
> Thanks,
> Martin
>
> In case you're curious about the background of the issue, my project is
> using the output of llvm-config --ldflags to set its linker flags.
> llvm-config is populating the output --ldflags with whatever it is given for
> CXX_LINK_FLAGS. CXX_LINK_FLAGS is being populated by the generic cmake logic
> in cmake.bbclass, which is getting its flags from BUILD_LDFLAGS in
> meta/conf/bitbake.conf.
I think we shoud not need rpaths for target recipes. We should see if we
can just remove it atleast for /lib /usr/lib
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Default rpaths in BUILD_LDFLAGS
2017-03-08 21:46 ` Khem Raj
@ 2017-03-08 21:56 ` Martin Kelly
2017-03-08 22:23 ` Khem Raj
0 siblings, 1 reply; 7+ messages in thread
From: Martin Kelly @ 2017-03-08 21:56 UTC (permalink / raw)
To: Khem Raj; +Cc: Enrico Scholz, Patches and discussions about the oe-core layer
On 03/08/2017 01:46 PM, Khem Raj wrote:
> On 17-03-07 16:43:47, Martin Kelly wrote:
>> Hi,
>>
>> While debugging an issue with a package that uses llvm-config to compile
>> with clang, I started hitting [rpaths] QA warnings because some output
>> executables contained absolute rpaths pointing into my build directory.
>> After tracing through the issue, I determined the rpaths to eventually be
>> originating from the setting of BUILD_LDFLAGS in meta/conf/bitbake.conf. The
>> rpath part of this was added in commit 35759f97 to the poky repo.
>
> thats for native packages alone.
>
You're right, it is for native packages only. That means this issue is
really specific to clang or other toolchains with similar issues rather
than being a general issue, which is good.
In this case, because llvm-config is built natively (as it needs to be
run on the build host), and because llvm-config populates its --ldflags
argument with the contents of BUILD_LDFLAGS, then the target build ends
up inheriting all these flags.
>>
>> In case you're curious about the background of the issue, my project is
>> using the output of llvm-config --ldflags to set its linker flags.
>> llvm-config is populating the output --ldflags with whatever it is given for
>> CXX_LINK_FLAGS. CXX_LINK_FLAGS is being populated by the generic cmake logic
>> in cmake.bbclass, which is getting its flags from BUILD_LDFLAGS in
>> meta/conf/bitbake.conf.
>
> I think we shoud not need rpaths for target recipes. We should see if we
> can just remove it atleast for /lib /usr/lib
>
I agree we should not need them. Of course I can run a sed line to
remove the rpaths from LLVM_LDFLAGS from
tools/llvm-config/BuildVariables.inc (and this works just fine).
However, I think there's a deeper issue here: All the build-time flags
that llvm-config spits out (--cppflags, --cflags, --cxxflags) probably
need to be replaced with target versions of those variables.
Do you agree with replacing all of those, or do you think we should
replace only the rpaths?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Default rpaths in BUILD_LDFLAGS
2017-03-08 21:56 ` Martin Kelly
@ 2017-03-08 22:23 ` Khem Raj
2017-03-08 23:44 ` Martin Kelly
0 siblings, 1 reply; 7+ messages in thread
From: Khem Raj @ 2017-03-08 22:23 UTC (permalink / raw)
To: Martin Kelly
Cc: Enrico Scholz, Patches and discussions about the oe-core layer
On 17-03-08 13:56:12, Martin Kelly wrote:
> On 03/08/2017 01:46 PM, Khem Raj wrote:
> > On 17-03-07 16:43:47, Martin Kelly wrote:
> > > Hi,
> > >
> > > While debugging an issue with a package that uses llvm-config to compile
> > > with clang, I started hitting [rpaths] QA warnings because some output
> > > executables contained absolute rpaths pointing into my build directory.
> > > After tracing through the issue, I determined the rpaths to eventually be
> > > originating from the setting of BUILD_LDFLAGS in meta/conf/bitbake.conf. The
> > > rpath part of this was added in commit 35759f97 to the poky repo.
> >
> > thats for native packages alone.
> >
>
> You're right, it is for native packages only. That means this issue is
> really specific to clang or other toolchains with similar issues rather than
> being a general issue, which is good.
>
> In this case, because llvm-config is built natively (as it needs to be run
> on the build host), and because llvm-config populates its --ldflags argument
> with the contents of BUILD_LDFLAGS, then the target build ends up inheriting
> all these flags.
>
> > >
> > > In case you're curious about the background of the issue, my project is
> > > using the output of llvm-config --ldflags to set its linker flags.
> > > llvm-config is populating the output --ldflags with whatever it is given for
> > > CXX_LINK_FLAGS. CXX_LINK_FLAGS is being populated by the generic cmake logic
> > > in cmake.bbclass, which is getting its flags from BUILD_LDFLAGS in
> > > meta/conf/bitbake.conf.
> >
> > I think we shoud not need rpaths for target recipes. We should see if we
> > can just remove it atleast for /lib /usr/lib
> >
>
> I agree we should not need them. Of course I can run a sed line to remove
> the rpaths from LLVM_LDFLAGS from tools/llvm-config/BuildVariables.inc (and
> this works just fine). However, I think there's a deeper issue here: All the
> build-time flags that llvm-config spits out (--cppflags, --cflags,
> --cxxflags) probably need to be replaced with target versions of those
> variables.
Its fine to sed it out, we are trying to use llvm-confing in a cross env
and this seems to be less treaded path for it, it assumes you would use
it for building packages natively generally.
>
> Do you agree with replacing all of those, or do you think we should replace
> only the rpaths?
yes please
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Default rpaths in BUILD_LDFLAGS
2017-03-08 22:23 ` Khem Raj
@ 2017-03-08 23:44 ` Martin Kelly
2017-03-09 0:02 ` Khem Raj
0 siblings, 1 reply; 7+ messages in thread
From: Martin Kelly @ 2017-03-08 23:44 UTC (permalink / raw)
To: Khem Raj; +Cc: Enrico Scholz, Patches and discussions about the oe-core layer
On 03/08/2017 02:23 PM, Khem Raj wrote:
> On 17-03-08 13:56:12, Martin Kelly wrote:
>> On 03/08/2017 01:46 PM, Khem Raj wrote:
>>
>> I agree we should not need them. Of course I can run a sed line to remove
>> the rpaths from LLVM_LDFLAGS from tools/llvm-config/BuildVariables.inc (and
>> this works just fine). However, I think there's a deeper issue here: All the
>> build-time flags that llvm-config spits out (--cppflags, --cflags,
>> --cxxflags) probably need to be replaced with target versions of those
>> variables.
>
> Its fine to sed it out, we are trying to use llvm-confing in a cross env
> and this seems to be less treaded path for it, it assumes you would use
> it for building packages natively generally.
>
>>
>> Do you agree with replacing all of those, or do you think we should replace
>> only the rpaths?
>
> yes please
>
Sorry, just to clarify, do you mean "yes, replace all of them", or "yes,
replace only the rpaths" ? :).
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Default rpaths in BUILD_LDFLAGS
2017-03-09 0:02 ` Khem Raj
@ 2017-03-09 0:01 ` Martin Kelly
0 siblings, 0 replies; 7+ messages in thread
From: Martin Kelly @ 2017-03-09 0:01 UTC (permalink / raw)
To: Khem Raj; +Cc: Enrico Scholz, Patches and discussions about the oe-core layer
On 03/08/2017 04:02 PM, Khem Raj wrote:
> On 17-03-08 15:44:52, Martin Kelly wrote:
>> On 03/08/2017 02:23 PM, Khem Raj wrote:
>>> On 17-03-08 13:56:12, Martin Kelly wrote:
>>>> On 03/08/2017 01:46 PM, Khem Raj wrote:
>>>>
>>>> I agree we should not need them. Of course I can run a sed line to remove
>>>> the rpaths from LLVM_LDFLAGS from tools/llvm-config/BuildVariables.inc (and
>>>> this works just fine). However, I think there's a deeper issue here: All the
>>>> build-time flags that llvm-config spits out (--cppflags, --cflags,
>>>> --cxxflags) probably need to be replaced with target versions of those
>>>> variables.
>>>
>>> Its fine to sed it out, we are trying to use llvm-confing in a cross env
>>> and this seems to be less treaded path for it, it assumes you would use
>>> it for building packages natively generally.
>>>
>>>>
>>>> Do you agree with replacing all of those, or do you think we should replace
>>>> only the rpaths?
>>>
>>> yes please
>>>
>>
>> Sorry, just to clarify, do you mean "yes, replace all of them", or "yes,
>> replace only the rpaths" ? :).
>
> Infact we should not use any part of BUILD_CFLAGS in determining target CFLAGS
> intead may be you can replace it with content of TARGET_CFLAGS
>
Thanks, agreed; I will replace all the relevant build paths with TARGET
versions of them.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Default rpaths in BUILD_LDFLAGS
2017-03-08 23:44 ` Martin Kelly
@ 2017-03-09 0:02 ` Khem Raj
2017-03-09 0:01 ` Martin Kelly
0 siblings, 1 reply; 7+ messages in thread
From: Khem Raj @ 2017-03-09 0:02 UTC (permalink / raw)
To: Martin Kelly
Cc: Enrico Scholz, Patches and discussions about the oe-core layer
On 17-03-08 15:44:52, Martin Kelly wrote:
> On 03/08/2017 02:23 PM, Khem Raj wrote:
> > On 17-03-08 13:56:12, Martin Kelly wrote:
> > > On 03/08/2017 01:46 PM, Khem Raj wrote:
> > >
> > > I agree we should not need them. Of course I can run a sed line to remove
> > > the rpaths from LLVM_LDFLAGS from tools/llvm-config/BuildVariables.inc (and
> > > this works just fine). However, I think there's a deeper issue here: All the
> > > build-time flags that llvm-config spits out (--cppflags, --cflags,
> > > --cxxflags) probably need to be replaced with target versions of those
> > > variables.
> >
> > Its fine to sed it out, we are trying to use llvm-confing in a cross env
> > and this seems to be less treaded path for it, it assumes you would use
> > it for building packages natively generally.
> >
> > >
> > > Do you agree with replacing all of those, or do you think we should replace
> > > only the rpaths?
> >
> > yes please
> >
>
> Sorry, just to clarify, do you mean "yes, replace all of them", or "yes,
> replace only the rpaths" ? :).
Infact we should not use any part of BUILD_CFLAGS in determining target CFLAGS
intead may be you can replace it with content of TARGET_CFLAGS
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-03-09 0:06 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-08 0:43 Default rpaths in BUILD_LDFLAGS Martin Kelly
2017-03-08 21:46 ` Khem Raj
2017-03-08 21:56 ` Martin Kelly
2017-03-08 22:23 ` Khem Raj
2017-03-08 23:44 ` Martin Kelly
2017-03-09 0:02 ` Khem Raj
2017-03-09 0:01 ` Martin Kelly
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.