[Xenomai] Won`t build on new Debian Stable

[Xenomai] Won`t build on new Debian Stable

[Norbert Lange]

Hello,

Building the xenomai package won`t work because debian now defaults to
using pie, and the linker will complain with "ld: -r and -pie may not
be used together"

A workaround for now is to add the flags manually:
../xenomai-3.0.5/configure LDFLAGS=-no-pie CFLAGS="-fno-PIE -fno-pie
-no-pie"

A real fix would be similar to
http://lists.gnu.org/archive/html/bug-grub/2016-11/msg00011.html
(no-pie is not supported on old and other compilers)

Kind regards,
Norbert

Re: [Xenomai] Won`t build on new Debian Stable

[Henning Schild]

Hi Norbert,

Thanks! In fact that issue has come up before and a similar workaround
was described. It should be fixed, patches welcome!

Henning

Am Wed, 9 Aug 2017 16:21:02 +0200
schrieb Norbert Lange <nolange79@gmail.com>:

> Hello,
> 
> Building the xenomai package won`t work because debian now defaults to
> using pie, and the linker will complain with "ld: -r and -pie may not
> be used together"
> 
> A workaround for now is to add the flags manually:
> ../xenomai-3.0.5/configure LDFLAGS=-no-pie CFLAGS="-fno-PIE -fno-pie
> -no-pie"
> 
> A real fix would be similar to
> http://lists.gnu.org/archive/html/bug-grub/2016-11/msg00011.html
> (no-pie is not supported on old and other compilers)
> 
> Kind regards,
> Norbert
> 
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Won`t build on new Debian Stable

[Norbert Lange]

Some highly trivial fix attached!
Its strange that this flag is not documented in the manual (I found
out abaout this fix from https://launchpad.net/ubuntu/+source/flint)

Norbert Lange

2017-08-10 11:49 GMT+02:00 Henning Schild <henning.schild@siemens.com>:
> Hi Norbert,
>
> Thanks! In fact that issue has come up before and a similar workaround
> was described. It should be fixed, patches welcome!
>
> Henning
>
> Am Wed, 9 Aug 2017 16:21:02 +0200
> schrieb Norbert Lange <nolange79@gmail.com>:
>
>> Hello,
>>
>> Building the xenomai package won`t work because debian now defaults to
>> using pie, and the linker will complain with "ld: -r and -pie may not
>> be used together"
>>
>> A workaround for now is to add the flags manually:
>> ../xenomai-3.0.5/configure LDFLAGS=-no-pie CFLAGS="-fno-PIE -fno-pie
>> -no-pie"
>>
>> A real fix would be similar to
>> http://lists.gnu.org/archive/html/bug-grub/2016-11/msg00011.html
>> (no-pie is not supported on old and other compilers)
>>
>> Kind regards,
>> Norbert
>>
>> _______________________________________________
>> Xenomai mailing list
>> Xenomai@xenomai.org
>> https://xenomai.org/mailman/listinfo/xenomai
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-allow-linking-with-pie-as-default.patch
Type: text/x-patch
Size: 1465 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20171010/21c189ff/attachment.bin>

Re: [Xenomai] Won`t build on new Debian Stable

[Henning Schild]

Hey Norbert,

thanks for looking into that again! Could you please explain how and
why that works, or point out what to look at in flint? Mailing list
thread, commit, something like that.

As far as i can see gcc now gets a "-r" which i do not find in the
manpage. And ld gets a "-U" which i do not find in its manpage. And
there is something about c++ constructors which might change the
behaviour of xenomai.

Henning

Am Tue, 10 Oct 2017 16:38:50 +0200
schrieb Norbert Lange <nolange79@gmail.com>:

> Some highly trivial fix attached!
> Its strange that this flag is not documented in the manual (I found
> out abaout this fix from https://launchpad.net/ubuntu/+source/flint)
> 
> Norbert Lange
> 
> 2017-08-10 11:49 GMT+02:00 Henning Schild
> <henning.schild@siemens.com>:
> > Hi Norbert,
> >
> > Thanks! In fact that issue has come up before and a similar
> > workaround was described. It should be fixed, patches welcome!
> >
> > Henning
> >
> > Am Wed, 9 Aug 2017 16:21:02 +0200
> > schrieb Norbert Lange <nolange79@gmail.com>:
> >  
> >> Hello,
> >>
> >> Building the xenomai package won`t work because debian now
> >> defaults to using pie, and the linker will complain with "ld: -r
> >> and -pie may not be used together"
> >>
> >> A workaround for now is to add the flags manually:
> >> ../xenomai-3.0.5/configure LDFLAGS=-no-pie CFLAGS="-fno-PIE
> >> -fno-pie -no-pie"
> >>
> >> A real fix would be similar to
> >> http://lists.gnu.org/archive/html/bug-grub/2016-11/msg00011.html
> >> (no-pie is not supported on old and other compilers)
> >>
> >> Kind regards,
> >> Norbert
> >>
> >> _______________________________________________
> >> Xenomai mailing list
> >> Xenomai@xenomai.org
> >> https://xenomai.org/mailman/listinfo/xenomai  
> >  

Re: [Xenomai] Won`t build on new Debian Stable

[Norbert Lange]

Hello,

I tracked down the source of information to this:
https://wiki.ubuntu.com/SecurityTeam/PIE

I changed the flags from "-Wl,-Ur" to "-Wl,-U -r", so you wont get an
explanation from me, why -U has to be passed for the linker.
And by the way, gcc accepts -U aswell, so this might be preferable to
be used directly too.

I don`t know why those flags aren' t documented, bug in gcc
documentation? As far as I understand is that gcc is smart enough to
correctly deal with the flags gcc directly received, but the linker
lacks that information.

I don' t know what the issue is with the C++ Constructors, in the
context of this change?
(I heard about the issues if those reside in a shared library, use
function from libcobald and don't depend on libcobald. Which is more
of a broken build to me if you don't add the depended libs, and will
bite you the same way if you use GCCs constructor attribute)

Kind regards,
Norbert.

2017-10-12 10:33 GMT+02:00 Henning Schild <henning.schild@siemens.com>:
> Hey Norbert,
>
> thanks for looking into that again! Could you please explain how and
> why that works, or point out what to look at in flint? Mailing list
> thread, commit, something like that.
>
> As far as i can see gcc now gets a "-r" which i do not find in the
> manpage. And ld gets a "-U" which i do not find in its manpage. And
> there is something about c++ constructors which might change the
> behaviour of xenomai.
>
> Henning
>
> Am Tue, 10 Oct 2017 16:38:50 +0200
> schrieb Norbert Lange <nolange79@gmail.com>:
>
>> Some highly trivial fix attached!
>> Its strange that this flag is not documented in the manual (I found
>> out abaout this fix from https://launchpad.net/ubuntu/+source/flint)
>>
>> Norbert Lange
>>
>> 2017-08-10 11:49 GMT+02:00 Henning Schild
>> <henning.schild@siemens.com>:
>> > Hi Norbert,
>> >
>> > Thanks! In fact that issue has come up before and a similar
>> > workaround was described. It should be fixed, patches welcome!
>> >
>> > Henning
>> >
>> > Am Wed, 9 Aug 2017 16:21:02 +0200
>> > schrieb Norbert Lange <nolange79@gmail.com>:
>> >
>> >> Hello,
>> >>
>> >> Building the xenomai package won`t work because debian now
>> >> defaults to using pie, and the linker will complain with "ld: -r
>> >> and -pie may not be used together"
>> >>
>> >> A workaround for now is to add the flags manually:
>> >> ../xenomai-3.0.5/configure LDFLAGS=-no-pie CFLAGS="-fno-PIE
>> >> -fno-pie -no-pie"
>> >>
>> >> A real fix would be similar to
>> >> http://lists.gnu.org/archive/html/bug-grub/2016-11/msg00011.html
>> >> (no-pie is not supported on old and other compilers)
>> >>
>> >> Kind regards,
>> >> Norbert
>> >>
>> >> _______________________________________________
>> >> Xenomai mailing list
>> >> Xenomai@xenomai.org
>> >> https://xenomai.org/mailman/listinfo/xenomai
>> >
>

Re: [Xenomai] Won`t build on new Debian Stable

[Norbert Lange]

Ok I just realized there is a "-Ur" option, aside from "-U -r".

You get alot otherwise undocumented flags with "gcc --help -v" BTW

2017-10-13 9:13 GMT+02:00 Norbert Lange <nolange79@gmail.com>:
> Hello,
>
> I tracked down the source of information to this:
> https://wiki.ubuntu.com/SecurityTeam/PIE
>
> I changed the flags from "-Wl,-Ur" to "-Wl,-U -r", so you wont get an
> explanation from me, why -U has to be passed for the linker.
> And by the way, gcc accepts -U aswell, so this might be preferable to
> be used directly too.
>
> I don`t know why those flags aren' t documented, bug in gcc
> documentation? As far as I understand is that gcc is smart enough to
> correctly deal with the flags gcc directly received, but the linker
> lacks that information.
>
> I don' t know what the issue is with the C++ Constructors, in the
> context of this change?
> (I heard about the issues if those reside in a shared library, use
> function from libcobald and don't depend on libcobald. Which is more
> of a broken build to me if you don't add the depended libs, and will
> bite you the same way if you use GCCs constructor attribute)
>
> Kind regards,
> Norbert.
>
> 2017-10-12 10:33 GMT+02:00 Henning Schild <henning.schild@siemens.com>:
>> Hey Norbert,
>>
>> thanks for looking into that again! Could you please explain how and
>> why that works, or point out what to look at in flint? Mailing list
>> thread, commit, something like that.
>>
>> As far as i can see gcc now gets a "-r" which i do not find in the
>> manpage. And ld gets a "-U" which i do not find in its manpage. And
>> there is something about c++ constructors which might change the
>> behaviour of xenomai.
>>
>> Henning
>>
>> Am Tue, 10 Oct 2017 16:38:50 +0200
>> schrieb Norbert Lange <nolange79@gmail.com>:
>>
>>> Some highly trivial fix attached!
>>> Its strange that this flag is not documented in the manual (I found
>>> out abaout this fix from https://launchpad.net/ubuntu/+source/flint)
>>>
>>> Norbert Lange
>>>
>>> 2017-08-10 11:49 GMT+02:00 Henning Schild
>>> <henning.schild@siemens.com>:
>>> > Hi Norbert,
>>> >
>>> > Thanks! In fact that issue has come up before and a similar
>>> > workaround was described. It should be fixed, patches welcome!
>>> >
>>> > Henning
>>> >
>>> > Am Wed, 9 Aug 2017 16:21:02 +0200
>>> > schrieb Norbert Lange <nolange79@gmail.com>:
>>> >
>>> >> Hello,
>>> >>
>>> >> Building the xenomai package won`t work because debian now
>>> >> defaults to using pie, and the linker will complain with "ld: -r
>>> >> and -pie may not be used together"
>>> >>
>>> >> A workaround for now is to add the flags manually:
>>> >> ../xenomai-3.0.5/configure LDFLAGS=-no-pie CFLAGS="-fno-PIE
>>> >> -fno-pie -no-pie"
>>> >>
>>> >> A real fix would be similar to
>>> >> http://lists.gnu.org/archive/html/bug-grub/2016-11/msg00011.html
>>> >> (no-pie is not supported on old and other compilers)
>>> >>
>>> >> Kind regards,
>>> >> Norbert
>>> >>
>>> >> _______________________________________________
>>> >> Xenomai mailing list
>>> >> Xenomai@xenomai.org
>>> >> https://xenomai.org/mailman/listinfo/xenomai
>>> >
>>

Re: [Xenomai] Won`t build on new Debian Stable

[Norbert Lange]

Second attempt at fixing it, you could surely make this more complex
using autohell but I am not going there.

If I understood correctly this script is only necessary if the
application is linked -static?
Means I would try to avoid using it, aslong I dont explicitly want to do that.

Kind regards,
Norbert

2017-10-13 9:40 GMT+02:00 Norbert Lange <nolange79@gmail.com>:
> Ok I just realized there is a "-Ur" option, aside from "-U -r".
>
> You get alot otherwise undocumented flags with "gcc --help -v" BTW
>
> 2017-10-13 9:13 GMT+02:00 Norbert Lange <nolange79@gmail.com>:
>> Hello,
>>
>> I tracked down the source of information to this:
>> https://wiki.ubuntu.com/SecurityTeam/PIE
>>
>> I changed the flags from "-Wl,-Ur" to "-Wl,-U -r", so you wont get an
>> explanation from me, why -U has to be passed for the linker.
>> And by the way, gcc accepts -U aswell, so this might be preferable to
>> be used directly too.
>>
>> I don`t know why those flags aren' t documented, bug in gcc
>> documentation? As far as I understand is that gcc is smart enough to
>> correctly deal with the flags gcc directly received, but the linker
>> lacks that information.
>>
>> I don' t know what the issue is with the C++ Constructors, in the
>> context of this change?
>> (I heard about the issues if those reside in a shared library, use
>> function from libcobald and don't depend on libcobald. Which is more
>> of a broken build to me if you don't add the depended libs, and will
>> bite you the same way if you use GCCs constructor attribute)
>>
>> Kind regards,
>> Norbert.
>>
>> 2017-10-12 10:33 GMT+02:00 Henning Schild <henning.schild@siemens.com>:
>>> Hey Norbert,
>>>
>>> thanks for looking into that again! Could you please explain how and
>>> why that works, or point out what to look at in flint? Mailing list
>>> thread, commit, something like that.
>>>
>>> As far as i can see gcc now gets a "-r" which i do not find in the
>>> manpage. And ld gets a "-U" which i do not find in its manpage. And
>>> there is something about c++ constructors which might change the
>>> behaviour of xenomai.
>>>
>>> Henning
>>>
>>> Am Tue, 10 Oct 2017 16:38:50 +0200
>>> schrieb Norbert Lange <nolange79@gmail.com>:
>>>
>>>> Some highly trivial fix attached!
>>>> Its strange that this flag is not documented in the manual (I found
>>>> out abaout this fix from https://launchpad.net/ubuntu/+source/flint)
>>>>
>>>> Norbert Lange
>>>>
>>>> 2017-08-10 11:49 GMT+02:00 Henning Schild
>>>> <henning.schild@siemens.com>:
>>>> > Hi Norbert,
>>>> >
>>>> > Thanks! In fact that issue has come up before and a similar
>>>> > workaround was described. It should be fixed, patches welcome!
>>>> >
>>>> > Henning
>>>> >
>>>> > Am Wed, 9 Aug 2017 16:21:02 +0200
>>>> > schrieb Norbert Lange <nolange79@gmail.com>:
>>>> >
>>>> >> Hello,
>>>> >>
>>>> >> Building the xenomai package won`t work because debian now
>>>> >> defaults to using pie, and the linker will complain with "ld: -r
>>>> >> and -pie may not be used together"
>>>> >>
>>>> >> A workaround for now is to add the flags manually:
>>>> >> ../xenomai-3.0.5/configure LDFLAGS=-no-pie CFLAGS="-fno-PIE
>>>> >> -fno-pie -no-pie"
>>>> >>
>>>> >> A real fix would be similar to
>>>> >> http://lists.gnu.org/archive/html/bug-grub/2016-11/msg00011.html
>>>> >> (no-pie is not supported on old and other compilers)
>>>> >>
>>>> >> Kind regards,
>>>> >> Norbert
>>>> >>
>>>> >> _______________________________________________
>>>> >> Xenomai mailing list
>>>> >> Xenomai@xenomai.org
>>>> >> https://xenomai.org/mailman/listinfo/xenomai
>>>> >
>>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_gcc_with_defaultpie_secondtry.patch
Type: text/x-patch
Size: 600 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20171013/23f4269f/attachment.bin>

Re: [Xenomai] Won`t build on new Debian Stable

[Henning Schild]

Am Fri, 13 Oct 2017 09:40:54 +0200
schrieb Norbert Lange <nolange79@gmail.com>:

> Ok I just realized there is a "-Ur" option, aside from "-U -r".

In the docs of ld there is _only_ "-Ur", "-U" is not there and "-r" is
not in the docs of gcc. Also when looking at "--help -v".

Henning

> You get alot otherwise undocumented flags with "gcc --help -v" BTW
> 
> 2017-10-13 9:13 GMT+02:00 Norbert Lange <nolange79@gmail.com>:
> > Hello,
> >
> > I tracked down the source of information to this:
> > https://wiki.ubuntu.com/SecurityTeam/PIE
> >
> > I changed the flags from "-Wl,-Ur" to "-Wl,-U -r", so you wont get
> > an explanation from me, why -U has to be passed for the linker.
> > And by the way, gcc accepts -U aswell, so this might be preferable
> > to be used directly too.
> >
> > I don`t know why those flags aren' t documented, bug in gcc
> > documentation? As far as I understand is that gcc is smart enough to
> > correctly deal with the flags gcc directly received, but the linker
> > lacks that information.
> >
> > I don' t know what the issue is with the C++ Constructors, in the
> > context of this change?
> > (I heard about the issues if those reside in a shared library, use
> > function from libcobald and don't depend on libcobald. Which is more
> > of a broken build to me if you don't add the depended libs, and will
> > bite you the same way if you use GCCs constructor attribute)
> >
> > Kind regards,
> > Norbert.
> >
> > 2017-10-12 10:33 GMT+02:00 Henning Schild
> > <henning.schild@siemens.com>:  
> >> Hey Norbert,
> >>
> >> thanks for looking into that again! Could you please explain how
> >> and why that works, or point out what to look at in flint? Mailing
> >> list thread, commit, something like that.
> >>
> >> As far as i can see gcc now gets a "-r" which i do not find in the
> >> manpage. And ld gets a "-U" which i do not find in its manpage. And
> >> there is something about c++ constructors which might change the
> >> behaviour of xenomai.
> >>
> >> Henning
> >>
> >> Am Tue, 10 Oct 2017 16:38:50 +0200
> >> schrieb Norbert Lange <nolange79@gmail.com>:
> >>  
> >>> Some highly trivial fix attached!
> >>> Its strange that this flag is not documented in the manual (I
> >>> found out abaout this fix from
> >>> https://launchpad.net/ubuntu/+source/flint)
> >>>
> >>> Norbert Lange
> >>>
> >>> 2017-08-10 11:49 GMT+02:00 Henning Schild
> >>> <henning.schild@siemens.com>:  
> >>> > Hi Norbert,
> >>> >
> >>> > Thanks! In fact that issue has come up before and a similar
> >>> > workaround was described. It should be fixed, patches welcome!
> >>> >
> >>> > Henning
> >>> >
> >>> > Am Wed, 9 Aug 2017 16:21:02 +0200
> >>> > schrieb Norbert Lange <nolange79@gmail.com>:
> >>> >  
> >>> >> Hello,
> >>> >>
> >>> >> Building the xenomai package won`t work because debian now
> >>> >> defaults to using pie, and the linker will complain with "ld:
> >>> >> -r and -pie may not be used together"
> >>> >>
> >>> >> A workaround for now is to add the flags manually:
> >>> >> ../xenomai-3.0.5/configure LDFLAGS=-no-pie CFLAGS="-fno-PIE
> >>> >> -fno-pie -no-pie"
> >>> >>
> >>> >> A real fix would be similar to
> >>> >> http://lists.gnu.org/archive/html/bug-grub/2016-11/msg00011.html
> >>> >> (no-pie is not supported on old and other compilers)
> >>> >>
> >>> >> Kind regards,
> >>> >> Norbert
> >>> >>
> >>> >> _______________________________________________
> >>> >> Xenomai mailing list
> >>> >> Xenomai@xenomai.org
> >>> >> https://xenomai.org/mailman/listinfo/xenomai  
> >>> >  
> >>  

Re: [Xenomai] Won`t build on new Debian Stable

[Henning Schild]

Am Fri, 13 Oct 2017 09:13:27 +0200
schrieb Norbert Lange <nolange79@gmail.com>:

> Hello,
> 
> I tracked down the source of information to this:
> https://wiki.ubuntu.com/SecurityTeam/PIE

Ok here they suggest to invoke gcc with "-r", which seems to be a
hidden undocumemted feature.

> I changed the flags from "-Wl,-Ur" to "-Wl,-U -r", so you wont get an

This passes "-r" to gcc and an invalid "-U" to ld. How about "-Wl,-Ur
-r" that would give the -r to ld and keep the c++ semantics.

> explanation from me, why -U has to be passed for the linker.
> And by the way, gcc accepts -U aswell, so this might be preferable to
> be used directly too.

"-U" in gcc seems to be for the preprocessor. To me that seems to be
something very different.

> I don`t know why those flags aren' t documented, bug in gcc
> documentation? As far as I understand is that gcc is smart enough to
> correctly deal with the flags gcc directly received, but the linker
> lacks that information.
> 
> I don' t know what the issue is with the C++ Constructors, in the
> context of this change?

I do not know whether there is an issue. But we have "-Ur" as ldflag in
there and your patch removes it.

> (I heard about the issues if those reside in a shared library, use
> function from libcobald and don't depend on libcobald. Which is more
> of a broken build to me if you don't add the depended libs, and will
> bite you the same way if you use GCCs constructor attribute)
> 
> Kind regards,
> Norbert.
> 
> 2017-10-12 10:33 GMT+02:00 Henning Schild
> <henning.schild@siemens.com>:
> > Hey Norbert,
> >
> > thanks for looking into that again! Could you please explain how and
> > why that works, or point out what to look at in flint? Mailing list
> > thread, commit, something like that.
> >
> > As far as i can see gcc now gets a "-r" which i do not find in the
> > manpage. And ld gets a "-U" which i do not find in its manpage. And
> > there is something about c++ constructors which might change the
> > behaviour of xenomai.
> >
> > Henning
> >
> > Am Tue, 10 Oct 2017 16:38:50 +0200
> > schrieb Norbert Lange <nolange79@gmail.com>:
> >  
> >> Some highly trivial fix attached!
> >> Its strange that this flag is not documented in the manual (I found
> >> out abaout this fix from
> >> https://launchpad.net/ubuntu/+source/flint)
> >>
> >> Norbert Lange
> >>
> >> 2017-08-10 11:49 GMT+02:00 Henning Schild
> >> <henning.schild@siemens.com>:  
> >> > Hi Norbert,
> >> >
> >> > Thanks! In fact that issue has come up before and a similar
> >> > workaround was described. It should be fixed, patches welcome!
> >> >
> >> > Henning
> >> >
> >> > Am Wed, 9 Aug 2017 16:21:02 +0200
> >> > schrieb Norbert Lange <nolange79@gmail.com>:
> >> >  
> >> >> Hello,
> >> >>
> >> >> Building the xenomai package won`t work because debian now
> >> >> defaults to using pie, and the linker will complain with "ld: -r
> >> >> and -pie may not be used together"
> >> >>
> >> >> A workaround for now is to add the flags manually:
> >> >> ../xenomai-3.0.5/configure LDFLAGS=-no-pie CFLAGS="-fno-PIE
> >> >> -fno-pie -no-pie"
> >> >>
> >> >> A real fix would be similar to
> >> >> http://lists.gnu.org/archive/html/bug-grub/2016-11/msg00011.html
> >> >> (no-pie is not supported on old and other compilers)
> >> >>
> >> >> Kind regards,
> >> >> Norbert
> >> >>
> >> >> _______________________________________________
> >> >> Xenomai mailing list
> >> >> Xenomai@xenomai.org
> >> >> https://xenomai.org/mailman/listinfo/xenomai  
> >> >  
> >  

Re: [Xenomai] Won`t build on new Debian Stable

[Henning Schild]

That looks good to me.

Henning

Am Fri, 13 Oct 2017 10:38:26 +0200
schrieb Norbert Lange <nolange79@gmail.com>:

> Second attempt at fixing it, you could surely make this more complex
> using autohell but I am not going there.
> 
> If I understood correctly this script is only necessary if the
> application is linked -static?
> Means I would try to avoid using it, aslong I dont explicitly want to
> do that.
> 
> Kind regards,
> Norbert
> 
> 2017-10-13 9:40 GMT+02:00 Norbert Lange <nolange79@gmail.com>:
> > Ok I just realized there is a "-Ur" option, aside from "-U -r".
> >
> > You get alot otherwise undocumented flags with "gcc --help -v" BTW
> >
> > 2017-10-13 9:13 GMT+02:00 Norbert Lange <nolange79@gmail.com>:  
> >> Hello,
> >>
> >> I tracked down the source of information to this:
> >> https://wiki.ubuntu.com/SecurityTeam/PIE
> >>
> >> I changed the flags from "-Wl,-Ur" to "-Wl,-U -r", so you wont get
> >> an explanation from me, why -U has to be passed for the linker.
> >> And by the way, gcc accepts -U aswell, so this might be preferable
> >> to be used directly too.
> >>
> >> I don`t know why those flags aren' t documented, bug in gcc
> >> documentation? As far as I understand is that gcc is smart enough
> >> to correctly deal with the flags gcc directly received, but the
> >> linker lacks that information.
> >>
> >> I don' t know what the issue is with the C++ Constructors, in the
> >> context of this change?
> >> (I heard about the issues if those reside in a shared library, use
> >> function from libcobald and don't depend on libcobald. Which is
> >> more of a broken build to me if you don't add the depended libs,
> >> and will bite you the same way if you use GCCs constructor
> >> attribute)
> >>
> >> Kind regards,
> >> Norbert.
> >>
> >> 2017-10-12 10:33 GMT+02:00 Henning Schild
> >> <henning.schild@siemens.com>:  
> >>> Hey Norbert,
> >>>
> >>> thanks for looking into that again! Could you please explain how
> >>> and why that works, or point out what to look at in flint?
> >>> Mailing list thread, commit, something like that.
> >>>
> >>> As far as i can see gcc now gets a "-r" which i do not find in the
> >>> manpage. And ld gets a "-U" which i do not find in its manpage.
> >>> And there is something about c++ constructors which might change
> >>> the behaviour of xenomai.
> >>>
> >>> Henning
> >>>
> >>> Am Tue, 10 Oct 2017 16:38:50 +0200
> >>> schrieb Norbert Lange <nolange79@gmail.com>:
> >>>  
> >>>> Some highly trivial fix attached!
> >>>> Its strange that this flag is not documented in the manual (I
> >>>> found out abaout this fix from
> >>>> https://launchpad.net/ubuntu/+source/flint)
> >>>>
> >>>> Norbert Lange
> >>>>
> >>>> 2017-08-10 11:49 GMT+02:00 Henning Schild
> >>>> <henning.schild@siemens.com>:  
> >>>> > Hi Norbert,
> >>>> >
> >>>> > Thanks! In fact that issue has come up before and a similar
> >>>> > workaround was described. It should be fixed, patches welcome!
> >>>> >
> >>>> > Henning
> >>>> >
> >>>> > Am Wed, 9 Aug 2017 16:21:02 +0200
> >>>> > schrieb Norbert Lange <nolange79@gmail.com>:
> >>>> >  
> >>>> >> Hello,
> >>>> >>
> >>>> >> Building the xenomai package won`t work because debian now
> >>>> >> defaults to using pie, and the linker will complain with "ld:
> >>>> >> -r and -pie may not be used together"
> >>>> >>
> >>>> >> A workaround for now is to add the flags manually:
> >>>> >> ../xenomai-3.0.5/configure LDFLAGS=-no-pie CFLAGS="-fno-PIE
> >>>> >> -fno-pie -no-pie"
> >>>> >>
> >>>> >> A real fix would be similar to
> >>>> >> http://lists.gnu.org/archive/html/bug-grub/2016-11/msg00011.html
> >>>> >> (no-pie is not supported on old and other compilers)
> >>>> >>
> >>>> >> Kind regards,
> >>>> >> Norbert
> >>>> >>
> >>>> >> _______________________________________________
> >>>> >> Xenomai mailing list
> >>>> >> Xenomai@xenomai.org
> >>>> >> https://xenomai.org/mailman/listinfo/xenomai  
> >>>> >  
> >>>  

Re: [Xenomai] Won`t build on new Debian Stable

[Norbert Lange]

Actually your idea of just adding -r would work aswell, and looks
cleaner and more robust to me.

I started with the wrong ideas because of the usual POSIX argument
parsing like "tar -xzf file.tar.gz" being interpreted as  "tar -x -z
-f file.tar.gz".

2017-10-13 11:31 GMT+02:00 Henning Schild <henning.schild@siemens.com>:
> That looks good to me.
>
> Henning
>
> Am Fri, 13 Oct 2017 10:38:26 +0200
> schrieb Norbert Lange <nolange79@gmail.com>:
>
>> Second attempt at fixing it, you could surely make this more complex
>> using autohell but I am not going there.
>>
>> If I understood correctly this script is only necessary if the
>> application is linked -static?
>> Means I would try to avoid using it, aslong I dont explicitly want to
>> do that.
>>
>> Kind regards,
>> Norbert
>>
>> 2017-10-13 9:40 GMT+02:00 Norbert Lange <nolange79@gmail.com>:
>> > Ok I just realized there is a "-Ur" option, aside from "-U -r".
>> >
>> > You get alot otherwise undocumented flags with "gcc --help -v" BTW
>> >
>> > 2017-10-13 9:13 GMT+02:00 Norbert Lange <nolange79@gmail.com>:
>> >> Hello,
>> >>
>> >> I tracked down the source of information to this:
>> >> https://wiki.ubuntu.com/SecurityTeam/PIE
>> >>
>> >> I changed the flags from "-Wl,-Ur" to "-Wl,-U -r", so you wont get
>> >> an explanation from me, why -U has to be passed for the linker.
>> >> And by the way, gcc accepts -U aswell, so this might be preferable
>> >> to be used directly too.
>> >>
>> >> I don`t know why those flags aren' t documented, bug in gcc
>> >> documentation? As far as I understand is that gcc is smart enough
>> >> to correctly deal with the flags gcc directly received, but the
>> >> linker lacks that information.
>> >>
>> >> I don' t know what the issue is with the C++ Constructors, in the
>> >> context of this change?
>> >> (I heard about the issues if those reside in a shared library, use
>> >> function from libcobald and don't depend on libcobald. Which is
>> >> more of a broken build to me if you don't add the depended libs,
>> >> and will bite you the same way if you use GCCs constructor
>> >> attribute)
>> >>
>> >> Kind regards,
>> >> Norbert.
>> >>
>> >> 2017-10-12 10:33 GMT+02:00 Henning Schild
>> >> <henning.schild@siemens.com>:
>> >>> Hey Norbert,
>> >>>
>> >>> thanks for looking into that again! Could you please explain how
>> >>> and why that works, or point out what to look at in flint?
>> >>> Mailing list thread, commit, something like that.
>> >>>
>> >>> As far as i can see gcc now gets a "-r" which i do not find in the
>> >>> manpage. And ld gets a "-U" which i do not find in its manpage.
>> >>> And there is something about c++ constructors which might change
>> >>> the behaviour of xenomai.
>> >>>
>> >>> Henning
>> >>>
>> >>> Am Tue, 10 Oct 2017 16:38:50 +0200
>> >>> schrieb Norbert Lange <nolange79@gmail.com>:
>> >>>
>> >>>> Some highly trivial fix attached!
>> >>>> Its strange that this flag is not documented in the manual (I
>> >>>> found out abaout this fix from
>> >>>> https://launchpad.net/ubuntu/+source/flint)
>> >>>>
>> >>>> Norbert Lange
>> >>>>
>> >>>> 2017-08-10 11:49 GMT+02:00 Henning Schild
>> >>>> <henning.schild@siemens.com>:
>> >>>> > Hi Norbert,
>> >>>> >
>> >>>> > Thanks! In fact that issue has come up before and a similar
>> >>>> > workaround was described. It should be fixed, patches welcome!
>> >>>> >
>> >>>> > Henning
>> >>>> >
>> >>>> > Am Wed, 9 Aug 2017 16:21:02 +0200
>> >>>> > schrieb Norbert Lange <nolange79@gmail.com>:
>> >>>> >
>> >>>> >> Hello,
>> >>>> >>
>> >>>> >> Building the xenomai package won`t work because debian now
>> >>>> >> defaults to using pie, and the linker will complain with "ld:
>> >>>> >> -r and -pie may not be used together"
>> >>>> >>
>> >>>> >> A workaround for now is to add the flags manually:
>> >>>> >> ../xenomai-3.0.5/configure LDFLAGS=-no-pie CFLAGS="-fno-PIE
>> >>>> >> -fno-pie -no-pie"
>> >>>> >>
>> >>>> >> A real fix would be similar to
>> >>>> >> http://lists.gnu.org/archive/html/bug-grub/2016-11/msg00011.html
>> >>>> >> (no-pie is not supported on old and other compilers)
>> >>>> >>
>> >>>> >> Kind regards,
>> >>>> >> Norbert
>> >>>> >>
>> >>>> >> _______________________________________________
>> >>>> >> Xenomai mailing list
>> >>>> >> Xenomai@xenomai.org
>> >>>> >> https://xenomai.org/mailman/listinfo/xenomai
>> >>>> >
>> >>>
>

Re: [Xenomai] Won`t build on new Debian Stable

[Henning Schild]

Am Fri, 13 Oct 2017 11:37:30 +0200
schrieb Norbert Lange <nolange79@gmail.com>:

> Actually your idea of just adding -r would work aswell, and looks
> cleaner and more robust to me.

Ok, in that case it would still be nice to understand why it works and
what "-r" does to gcc.

If you like that better send another patch and we will see what
Philippe says.

Henning

> I started with the wrong ideas because of the usual POSIX argument
> parsing like "tar -xzf file.tar.gz" being interpreted as  "tar -x -z
> -f file.tar.gz".
> 
> 2017-10-13 11:31 GMT+02:00 Henning Schild
> <henning.schild@siemens.com>:
> > That looks good to me.
> >
> > Henning
> >
> > Am Fri, 13 Oct 2017 10:38:26 +0200
> > schrieb Norbert Lange <nolange79@gmail.com>:
> >  
> >> Second attempt at fixing it, you could surely make this more
> >> complex using autohell but I am not going there.
> >>
> >> If I understood correctly this script is only necessary if the
> >> application is linked -static?
> >> Means I would try to avoid using it, aslong I dont explicitly want
> >> to do that.
> >>
> >> Kind regards,
> >> Norbert
> >>
> >> 2017-10-13 9:40 GMT+02:00 Norbert Lange <nolange79@gmail.com>:  
> >> > Ok I just realized there is a "-Ur" option, aside from "-U -r".
> >> >
> >> > You get alot otherwise undocumented flags with "gcc --help -v"
> >> > BTW
> >> >
> >> > 2017-10-13 9:13 GMT+02:00 Norbert Lange <nolange79@gmail.com>:  
> >> >> Hello,
> >> >>
> >> >> I tracked down the source of information to this:
> >> >> https://wiki.ubuntu.com/SecurityTeam/PIE
> >> >>
> >> >> I changed the flags from "-Wl,-Ur" to "-Wl,-U -r", so you wont
> >> >> get an explanation from me, why -U has to be passed for the
> >> >> linker. And by the way, gcc accepts -U aswell, so this might be
> >> >> preferable to be used directly too.
> >> >>
> >> >> I don`t know why those flags aren' t documented, bug in gcc
> >> >> documentation? As far as I understand is that gcc is smart
> >> >> enough to correctly deal with the flags gcc directly received,
> >> >> but the linker lacks that information.
> >> >>
> >> >> I don' t know what the issue is with the C++ Constructors, in
> >> >> the context of this change?
> >> >> (I heard about the issues if those reside in a shared library,
> >> >> use function from libcobald and don't depend on libcobald.
> >> >> Which is more of a broken build to me if you don't add the
> >> >> depended libs, and will bite you the same way if you use GCCs
> >> >> constructor attribute)
> >> >>
> >> >> Kind regards,
> >> >> Norbert.
> >> >>
> >> >> 2017-10-12 10:33 GMT+02:00 Henning Schild
> >> >> <henning.schild@siemens.com>:  
> >> >>> Hey Norbert,
> >> >>>
> >> >>> thanks for looking into that again! Could you please explain
> >> >>> how and why that works, or point out what to look at in flint?
> >> >>> Mailing list thread, commit, something like that.
> >> >>>
> >> >>> As far as i can see gcc now gets a "-r" which i do not find in
> >> >>> the manpage. And ld gets a "-U" which i do not find in its
> >> >>> manpage. And there is something about c++ constructors which
> >> >>> might change the behaviour of xenomai.
> >> >>>
> >> >>> Henning
> >> >>>
> >> >>> Am Tue, 10 Oct 2017 16:38:50 +0200
> >> >>> schrieb Norbert Lange <nolange79@gmail.com>:
> >> >>>  
> >> >>>> Some highly trivial fix attached!
> >> >>>> Its strange that this flag is not documented in the manual (I
> >> >>>> found out abaout this fix from
> >> >>>> https://launchpad.net/ubuntu/+source/flint)
> >> >>>>
> >> >>>> Norbert Lange
> >> >>>>
> >> >>>> 2017-08-10 11:49 GMT+02:00 Henning Schild
> >> >>>> <henning.schild@siemens.com>:  
> >> >>>> > Hi Norbert,
> >> >>>> >
> >> >>>> > Thanks! In fact that issue has come up before and a similar
> >> >>>> > workaround was described. It should be fixed, patches
> >> >>>> > welcome!
> >> >>>> >
> >> >>>> > Henning
> >> >>>> >
> >> >>>> > Am Wed, 9 Aug 2017 16:21:02 +0200
> >> >>>> > schrieb Norbert Lange <nolange79@gmail.com>:
> >> >>>> >  
> >> >>>> >> Hello,
> >> >>>> >>
> >> >>>> >> Building the xenomai package won`t work because debian now
> >> >>>> >> defaults to using pie, and the linker will complain with
> >> >>>> >> "ld: -r and -pie may not be used together"
> >> >>>> >>
> >> >>>> >> A workaround for now is to add the flags manually:
> >> >>>> >> ../xenomai-3.0.5/configure LDFLAGS=-no-pie CFLAGS="-fno-PIE
> >> >>>> >> -fno-pie -no-pie"
> >> >>>> >>
> >> >>>> >> A real fix would be similar to
> >> >>>> >> http://lists.gnu.org/archive/html/bug-grub/2016-11/msg00011.html
> >> >>>> >> (no-pie is not supported on old and other compilers)
> >> >>>> >>
> >> >>>> >> Kind regards,
> >> >>>> >> Norbert
> >> >>>> >>
> >> >>>> >> _______________________________________________
> >> >>>> >> Xenomai mailing list
> >> >>>> >> Xenomai@xenomai.org
> >> >>>> >> https://xenomai.org/mailman/listinfo/xenomai  
> >> >>>> >  
> >> >>>  
> >  

Re: [Xenomai] Won`t build on new Debian Stable

[Norbert Lange]

I works, because collect2 (the "compiler driver", which documents the
-r option) now knows about the -r flag, using -Wl,-[U]r would mean the
flags aren't even looked at.
It can then disable functionality that is not supposed to be done at
this point (see gcc/collect2.c, search for 'early_exit'). It might
actually be in conflict with the -Ur option from the comments, but I
don't know what this is trying to solve (the constructor tables would
then be built in the second step?)

I would prefer the compiler driver knowing about the flags and
correctly dealing with them, instead of replicating this logic in
scripts (and keeping it up to date with this internal logic).
Might be that your wrapper script is doing something similarly by
filtering out the arguments for the first step, which might be the
same functionally that is skipped when adding '-r'

I dont know what the -Ur flag is trying to solve, and the first patch
adding -no-pie is way less likely to change something (given that I
would not have compiled with -pie before).
The new patch would however leave more of the magic to the toolchain
and seems more "correct" to me, for whatever that's worth. But it
might have some subtle differences to before, got some testcase where
lacking the -Ur flag made a difference?



2017-10-13 12:26 GMT+02:00 Henning Schild <henning.schild@siemens.com>:
> Am Fri, 13 Oct 2017 11:37:30 +0200
> schrieb Norbert Lange <nolange79@gmail.com>:
>
>> Actually your idea of just adding -r would work aswell, and looks
>> cleaner and more robust to me.
>
> Ok, in that case it would still be nice to understand why it works and
> what "-r" does to gcc.
>
> If you like that better send another patch and we will see what
> Philippe says.
>
> Henning
>
>> I started with the wrong ideas because of the usual POSIX argument
>> parsing like "tar -xzf file.tar.gz" being interpreted as  "tar -x -z
>> -f file.tar.gz".
>>
>> 2017-10-13 11:31 GMT+02:00 Henning Schild
>> <henning.schild@siemens.com>:
>> > That looks good to me.
>> >
>> > Henning
>> >
>> > Am Fri, 13 Oct 2017 10:38:26 +0200
>> > schrieb Norbert Lange <nolange79@gmail.com>:
>> >
>> >> Second attempt at fixing it, you could surely make this more
>> >> complex using autohell but I am not going there.
>> >>
>> >> If I understood correctly this script is only necessary if the
>> >> application is linked -static?
>> >> Means I would try to avoid using it, aslong I dont explicitly want
>> >> to do that.
>> >>
>> >> Kind regards,
>> >> Norbert
>> >>
>> >> 2017-10-13 9:40 GMT+02:00 Norbert Lange <nolange79@gmail.com>:
>> >> > Ok I just realized there is a "-Ur" option, aside from "-U -r".
>> >> >
>> >> > You get alot otherwise undocumented flags with "gcc --help -v"
>> >> > BTW
>> >> >
>> >> > 2017-10-13 9:13 GMT+02:00 Norbert Lange <nolange79@gmail.com>:
>> >> >> Hello,
>> >> >>
>> >> >> I tracked down the source of information to this:
>> >> >> https://wiki.ubuntu.com/SecurityTeam/PIE
>> >> >>
>> >> >> I changed the flags from "-Wl,-Ur" to "-Wl,-U -r", so you wont
>> >> >> get an explanation from me, why -U has to be passed for the
>> >> >> linker. And by the way, gcc accepts -U aswell, so this might be
>> >> >> preferable to be used directly too.
>> >> >>
>> >> >> I don`t know why those flags aren' t documented, bug in gcc
>> >> >> documentation? As far as I understand is that gcc is smart
>> >> >> enough to correctly deal with the flags gcc directly received,
>> >> >> but the linker lacks that information.
>> >> >>
>> >> >> I don' t know what the issue is with the C++ Constructors, in
>> >> >> the context of this change?
>> >> >> (I heard about the issues if those reside in a shared library,
>> >> >> use function from libcobald and don't depend on libcobald.
>> >> >> Which is more of a broken build to me if you don't add the
>> >> >> depended libs, and will bite you the same way if you use GCCs
>> >> >> constructor attribute)
>> >> >>
>> >> >> Kind regards,
>> >> >> Norbert.
>> >> >>
>> >> >> 2017-10-12 10:33 GMT+02:00 Henning Schild
>> >> >> <henning.schild@siemens.com>:
>> >> >>> Hey Norbert,
>> >> >>>
>> >> >>> thanks for looking into that again! Could you please explain
>> >> >>> how and why that works, or point out what to look at in flint?
>> >> >>> Mailing list thread, commit, something like that.
>> >> >>>
>> >> >>> As far as i can see gcc now gets a "-r" which i do not find in
>> >> >>> the manpage. And ld gets a "-U" which i do not find in its
>> >> >>> manpage. And there is something about c++ constructors which
>> >> >>> might change the behaviour of xenomai.
>> >> >>>
>> >> >>> Henning
>> >> >>>
>> >> >>> Am Tue, 10 Oct 2017 16:38:50 +0200
>> >> >>> schrieb Norbert Lange <nolange79@gmail.com>:
>> >> >>>
>> >> >>>> Some highly trivial fix attached!
>> >> >>>> Its strange that this flag is not documented in the manual (I
>> >> >>>> found out abaout this fix from
>> >> >>>> https://launchpad.net/ubuntu/+source/flint)
>> >> >>>>
>> >> >>>> Norbert Lange
>> >> >>>>
>> >> >>>> 2017-08-10 11:49 GMT+02:00 Henning Schild
>> >> >>>> <henning.schild@siemens.com>:
>> >> >>>> > Hi Norbert,
>> >> >>>> >
>> >> >>>> > Thanks! In fact that issue has come up before and a similar
>> >> >>>> > workaround was described. It should be fixed, patches
>> >> >>>> > welcome!
>> >> >>>> >
>> >> >>>> > Henning
>> >> >>>> >
>> >> >>>> > Am Wed, 9 Aug 2017 16:21:02 +0200
>> >> >>>> > schrieb Norbert Lange <nolange79@gmail.com>:
>> >> >>>> >
>> >> >>>> >> Hello,
>> >> >>>> >>
>> >> >>>> >> Building the xenomai package won`t work because debian now
>> >> >>>> >> defaults to using pie, and the linker will complain with
>> >> >>>> >> "ld: -r and -pie may not be used together"
>> >> >>>> >>
>> >> >>>> >> A workaround for now is to add the flags manually:
>> >> >>>> >> ../xenomai-3.0.5/configure LDFLAGS=-no-pie CFLAGS="-fno-PIE
>> >> >>>> >> -fno-pie -no-pie"
>> >> >>>> >>
>> >> >>>> >> A real fix would be similar to
>> >> >>>> >> http://lists.gnu.org/archive/html/bug-grub/2016-11/msg00011.html
>> >> >>>> >> (no-pie is not supported on old and other compilers)
>> >> >>>> >>
>> >> >>>> >> Kind regards,
>> >> >>>> >> Norbert
>> >> >>>> >>
>> >> >>>> >> _______________________________________________
>> >> >>>> >> Xenomai mailing list
>> >> >>>> >> Xenomai@xenomai.org
>> >> >>>> >> https://xenomai.org/mailman/listinfo/xenomai
>> >> >>>> >
>> >> >>>
>> >
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-build-with-gcc-using-default-PIE.patch
Type: text/x-patch
Size: 742 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20171013/0b3aaf80/attachment.bin>

Re: [Xenomai] Won`t build on new Debian Stable

[Norbert Lange]

Sorry, wrong file attached.

2017-10-13 13:36 GMT+02:00 Norbert Lange <nolange79@gmail.com>:
> I works, because collect2 (the "compiler driver", which documents the
> -r option) now knows about the -r flag, using -Wl,-[U]r would mean the
> flags aren't even looked at.
> It can then disable functionality that is not supposed to be done at
> this point (see gcc/collect2.c, search for 'early_exit'). It might
> actually be in conflict with the -Ur option from the comments, but I
> don't know what this is trying to solve (the constructor tables would
> then be built in the second step?)
>
> I would prefer the compiler driver knowing about the flags and
> correctly dealing with them, instead of replicating this logic in
> scripts (and keeping it up to date with this internal logic).
> Might be that your wrapper script is doing something similarly by
> filtering out the arguments for the first step, which might be the
> same functionally that is skipped when adding '-r'
>
> I dont know what the -Ur flag is trying to solve, and the first patch
> adding -no-pie is way less likely to change something (given that I
> would not have compiled with -pie before).
> The new patch would however leave more of the magic to the toolchain
> and seems more "correct" to me, for whatever that's worth. But it
> might have some subtle differences to before, got some testcase where
> lacking the -Ur flag made a difference?
>
>
>
> 2017-10-13 12:26 GMT+02:00 Henning Schild <henning.schild@siemens.com>:
>> Am Fri, 13 Oct 2017 11:37:30 +0200
>> schrieb Norbert Lange <nolange79@gmail.com>:
>>
>>> Actually your idea of just adding -r would work aswell, and looks
>>> cleaner and more robust to me.
>>
>> Ok, in that case it would still be nice to understand why it works and
>> what "-r" does to gcc.
>>
>> If you like that better send another patch and we will see what
>> Philippe says.
>>
>> Henning
>>
>>> I started with the wrong ideas because of the usual POSIX argument
>>> parsing like "tar -xzf file.tar.gz" being interpreted as  "tar -x -z
>>> -f file.tar.gz".
>>>
>>> 2017-10-13 11:31 GMT+02:00 Henning Schild
>>> <henning.schild@siemens.com>:
>>> > That looks good to me.
>>> >
>>> > Henning
>>> >
>>> > Am Fri, 13 Oct 2017 10:38:26 +0200
>>> > schrieb Norbert Lange <nolange79@gmail.com>:
>>> >
>>> >> Second attempt at fixing it, you could surely make this more
>>> >> complex using autohell but I am not going there.
>>> >>
>>> >> If I understood correctly this script is only necessary if the
>>> >> application is linked -static?
>>> >> Means I would try to avoid using it, aslong I dont explicitly want
>>> >> to do that.
>>> >>
>>> >> Kind regards,
>>> >> Norbert
>>> >>
>>> >> 2017-10-13 9:40 GMT+02:00 Norbert Lange <nolange79@gmail.com>:
>>> >> > Ok I just realized there is a "-Ur" option, aside from "-U -r".
>>> >> >
>>> >> > You get alot otherwise undocumented flags with "gcc --help -v"
>>> >> > BTW
>>> >> >
>>> >> > 2017-10-13 9:13 GMT+02:00 Norbert Lange <nolange79@gmail.com>:
>>> >> >> Hello,
>>> >> >>
>>> >> >> I tracked down the source of information to this:
>>> >> >> https://wiki.ubuntu.com/SecurityTeam/PIE
>>> >> >>
>>> >> >> I changed the flags from "-Wl,-Ur" to "-Wl,-U -r", so you wont
>>> >> >> get an explanation from me, why -U has to be passed for the
>>> >> >> linker. And by the way, gcc accepts -U aswell, so this might be
>>> >> >> preferable to be used directly too.
>>> >> >>
>>> >> >> I don`t know why those flags aren' t documented, bug in gcc
>>> >> >> documentation? As far as I understand is that gcc is smart
>>> >> >> enough to correctly deal with the flags gcc directly received,
>>> >> >> but the linker lacks that information.
>>> >> >>
>>> >> >> I don' t know what the issue is with the C++ Constructors, in
>>> >> >> the context of this change?
>>> >> >> (I heard about the issues if those reside in a shared library,
>>> >> >> use function from libcobald and don't depend on libcobald.
>>> >> >> Which is more of a broken build to me if you don't add the
>>> >> >> depended libs, and will bite you the same way if you use GCCs
>>> >> >> constructor attribute)
>>> >> >>
>>> >> >> Kind regards,
>>> >> >> Norbert.
>>> >> >>
>>> >> >> 2017-10-12 10:33 GMT+02:00 Henning Schild
>>> >> >> <henning.schild@siemens.com>:
>>> >> >>> Hey Norbert,
>>> >> >>>
>>> >> >>> thanks for looking into that again! Could you please explain
>>> >> >>> how and why that works, or point out what to look at in flint?
>>> >> >>> Mailing list thread, commit, something like that.
>>> >> >>>
>>> >> >>> As far as i can see gcc now gets a "-r" which i do not find in
>>> >> >>> the manpage. And ld gets a "-U" which i do not find in its
>>> >> >>> manpage. And there is something about c++ constructors which
>>> >> >>> might change the behaviour of xenomai.
>>> >> >>>
>>> >> >>> Henning
>>> >> >>>
>>> >> >>> Am Tue, 10 Oct 2017 16:38:50 +0200
>>> >> >>> schrieb Norbert Lange <nolange79@gmail.com>:
>>> >> >>>
>>> >> >>>> Some highly trivial fix attached!
>>> >> >>>> Its strange that this flag is not documented in the manual (I
>>> >> >>>> found out abaout this fix from
>>> >> >>>> https://launchpad.net/ubuntu/+source/flint)
>>> >> >>>>
>>> >> >>>> Norbert Lange
>>> >> >>>>
>>> >> >>>> 2017-08-10 11:49 GMT+02:00 Henning Schild
>>> >> >>>> <henning.schild@siemens.com>:
>>> >> >>>> > Hi Norbert,
>>> >> >>>> >
>>> >> >>>> > Thanks! In fact that issue has come up before and a similar
>>> >> >>>> > workaround was described. It should be fixed, patches
>>> >> >>>> > welcome!
>>> >> >>>> >
>>> >> >>>> > Henning
>>> >> >>>> >
>>> >> >>>> > Am Wed, 9 Aug 2017 16:21:02 +0200
>>> >> >>>> > schrieb Norbert Lange <nolange79@gmail.com>:
>>> >> >>>> >
>>> >> >>>> >> Hello,
>>> >> >>>> >>
>>> >> >>>> >> Building the xenomai package won`t work because debian now
>>> >> >>>> >> defaults to using pie, and the linker will complain with
>>> >> >>>> >> "ld: -r and -pie may not be used together"
>>> >> >>>> >>
>>> >> >>>> >> A workaround for now is to add the flags manually:
>>> >> >>>> >> ../xenomai-3.0.5/configure LDFLAGS=-no-pie CFLAGS="-fno-PIE
>>> >> >>>> >> -fno-pie -no-pie"
>>> >> >>>> >>
>>> >> >>>> >> A real fix would be similar to
>>> >> >>>> >> http://lists.gnu.org/archive/html/bug-grub/2016-11/msg00011.html
>>> >> >>>> >> (no-pie is not supported on old and other compilers)
>>> >> >>>> >>
>>> >> >>>> >> Kind regards,
>>> >> >>>> >> Norbert
>>> >> >>>> >>
>>> >> >>>> >> _______________________________________________
>>> >> >>>> >> Xenomai mailing list
>>> >> >>>> >> Xenomai@xenomai.org
>>> >> >>>> >> https://xenomai.org/mailman/listinfo/xenomai
>>> >> >>>> >
>>> >> >>>
>>> >
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-build-with-gcc-using-default-PIE_v2.patch
Type: text/x-patch
Size: 746 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20171013/74d33949/attachment.bin>

Re: [Xenomai] Won`t build on new Debian Stable

[Philippe Gerum]

On 10/13/2017 01:36 PM, Norbert Lange wrote:
> I works, because collect2 (the "compiler driver", which documents the
> -r option) now knows about the -r flag, using -Wl,-[U]r would mean the
> flags aren't even looked at.
> It can then disable functionality that is not supposed to be done at
> this point (see gcc/collect2.c, search for 'early_exit'). It might
> actually be in conflict with the -Ur option from the comments, but I
> don't know what this is trying to solve (the constructor tables would
> then be built in the second step?)
> 
> I would prefer the compiler driver knowing about the flags and
> correctly dealing with them, instead of replicating this logic in
> scripts (and keeping it up to date with this internal logic).

Ack.

> Might be that your wrapper script is doing something similarly by
> filtering out the arguments for the first step, which might be the
> same functionally that is skipped when adding '-r'
> 
> I dont know what the -Ur flag is trying to solve, and the first patch
> adding -no-pie is way less likely to change something (given that I
> would not have compiled with -pie before).
> The new patch would however leave more of the magic to the toolchain
> and seems more "correct" to me, for whatever that's worth. But it
> might have some subtle differences to before, got some testcase where
> lacking the -Ur flag made a difference?

I don't know the original intent about passing -Ur to the linker, except
maybe to stick to the ld manpage which states that the last partial link
command should be given such option.

However my understanding is that we don't need it in wrap-link.sh, since
the script eventually completes the link stage to produce a fully
resolved executable. That implies collecting the ctors/dtors and
resolving all references from the partially linked object file anyway.

Some testing only passing -r here seems to confirm this assumption with
C++ apps; C++ users may want to check this too:

diff --git a/scripts/wrap-link.sh b/scripts/wrap-link.sh
index aab7899..fa83bd5 100755
--- a/scripts/wrap-link.sh
+++ b/scripts/wrap-link.sh
@@ -204,7 +204,7 @@ done

 if $stage2; then
     $verbose && set -x
-    $dryrun $cc -o "$output.tmp" -Wl,-Ur -nostdlib $stage1_args
+    $dryrun $cc -o "$output.tmp" -r -nostdlib $stage1_args
     $dryrun $cc -o "$output" "$output.tmp" $stage2_args
     $dryrun rm -f $output.tmp
 else

-- 
Philippe.

Re: [Xenomai] Won`t build on new Debian Stable

[Philippe Gerum]

On 10/19/2017 01:32 PM, Lange Norbert wrote:
> Hello,
> 
>> I don't know the original intent about passing -Ur to the linker, except
>  >maybe to stick to the ld manpage which states that the last partial link
>  >command should be given such option.
> 
> I understand that differently, you can't use this flag in anything but the
> last partial link. Not that you should do it.

Which is my interpretation as well.

> 
> Further I agree that -Ur is, to my best knowledge, not needed at all.
> It might make sense if you want to do something directly with the
> Resulting object, but if final link to App or Library is some "standard"
> link then the tables are built there.
> It might actually create problems if some symbols (weak, inline)
> would be resolved differently in the final link.
> 
> Further, if I look at this ld switch:
> " --warn-constructors
> Warn if any global constructors are used. This is only useful for a few object file formats.
> For formats like COFF or ELF, the linker can not detect the use of global constructors."
>

Maybe not (although it is not obvious reading the binutils/ld code
populating the linker's hash table), but ld knows about collect2, which
detects such use.

> Then I am not even sure the linker will do ANYTHING differently with -Ur for ELF.> Such constructor functions pointers are placed in a special linker
section ".init_array",
> and the startup-code or the dynamic loader iterates on that array. There is
> nothing C++ specific.

I would assume the opposite. The ld doc says: "When linking C ++
programs, -Ur does resolve references to constructors". Also, the
previous discussion referred to collect2 as the breaking point when -r
and -pie conflict, which confirms it may be a C++ specific issue given
the purpose of collect2, which triggers due to a discrepancy between
gcc, collect2 and ld when it comes to partially linking pie code.

In addition, my understanding is that those references you mention are
not directly handled as ELF constructor routines, but indirectly by an
init handler called by the early C++ runtime code, which iterates over
those tables (over glibc's libc_start_main entry point for the ctor part).

> 
> How about using your supposed change and adding some comments that
> "-Wl,-Ur" was removed as hint?
> 

I asked earlier for C++ users to test that change in wrap-link.sh first,
not to break the stable branch for them. If nobody complains after a
couple of weeks, the change should definitely be merged.

-- 
Philippe.

Re: [Xenomai] Won`t build on new Debian Stable

[Henning Schild]

On Thu, 19 Oct 2017 12:03:33 +0200
Philippe Gerum <rpm@xenomai.org> wrote:

> On 10/13/2017 01:36 PM, Norbert Lange wrote:
> > I works, because collect2 (the "compiler driver", which documents
> > the -r option) now knows about the -r flag, using -Wl,-[U]r would
> > mean the flags aren't even looked at.
> > It can then disable functionality that is not supposed to be done at
> > this point (see gcc/collect2.c, search for 'early_exit'). It might
> > actually be in conflict with the -Ur option from the comments, but I
> > don't know what this is trying to solve (the constructor tables
> > would then be built in the second step?)
> > 
> > I would prefer the compiler driver knowing about the flags and
> > correctly dealing with them, instead of replicating this logic in
> > scripts (and keeping it up to date with this internal logic).  
> 
> Ack.
> 
> > Might be that your wrapper script is doing something similarly by
> > filtering out the arguments for the first step, which might be the
> > same functionally that is skipped when adding '-r'
> > 
> > I dont know what the -Ur flag is trying to solve, and the first
> > patch adding -no-pie is way less likely to change something (given
> > that I would not have compiled with -pie before).
> > The new patch would however leave more of the magic to the toolchain
> > and seems more "correct" to me, for whatever that's worth. But it
> > might have some subtle differences to before, got some testcase
> > where lacking the -Ur flag made a difference?  
> 
> I don't know the original intent about passing -Ur to the linker,
> except maybe to stick to the ld manpage which states that the last
> partial link command should be given such option.
> 
> However my understanding is that we don't need it in wrap-link.sh,
> since the script eventually completes the link stage to produce a
> fully resolved executable. That implies collecting the ctors/dtors and
> resolving all references from the partially linked object file anyway.
> 
> Some testing only passing -r here seems to confirm this assumption
> with C++ apps; C++ users may want to check this too:

I just told some C++ power users to give that a try. I am not sure how
fast the feedback will arrive, i hope in the next two weeks.

Henning

> 
> diff --git a/scripts/wrap-link.sh b/scripts/wrap-link.sh
> index aab7899..fa83bd5 100755
> --- a/scripts/wrap-link.sh
> +++ b/scripts/wrap-link.sh
> @@ -204,7 +204,7 @@ done
> 
>  if $stage2; then
>      $verbose && set -x
> -    $dryrun $cc -o "$output.tmp" -Wl,-Ur -nostdlib $stage1_args
> +    $dryrun $cc -o "$output.tmp" -r -nostdlib $stage1_args
>      $dryrun $cc -o "$output" "$output.tmp" $stage2_args
>      $dryrun rm -f $output.tmp
>  else
> 

Re: [Xenomai] Won`t build on new Debian Stable

[Philippe Gerum]

On 10/19/2017 06:55 PM, Henning Schild wrote:
> On Thu, 19 Oct 2017 12:03:33 +0200
> Philippe Gerum <rpm@xenomai.org> wrote:
> 
>> On 10/13/2017 01:36 PM, Norbert Lange wrote:
>>> I works, because collect2 (the "compiler driver", which documents
>>> the -r option) now knows about the -r flag, using -Wl,-[U]r would
>>> mean the flags aren't even looked at.
>>> It can then disable functionality that is not supposed to be done at
>>> this point (see gcc/collect2.c, search for 'early_exit'). It might
>>> actually be in conflict with the -Ur option from the comments, but I
>>> don't know what this is trying to solve (the constructor tables
>>> would then be built in the second step?)
>>>
>>> I would prefer the compiler driver knowing about the flags and
>>> correctly dealing with them, instead of replicating this logic in
>>> scripts (and keeping it up to date with this internal logic).  
>>
>> Ack.
>>
>>> Might be that your wrapper script is doing something similarly by
>>> filtering out the arguments for the first step, which might be the
>>> same functionally that is skipped when adding '-r'
>>>
>>> I dont know what the -Ur flag is trying to solve, and the first
>>> patch adding -no-pie is way less likely to change something (given
>>> that I would not have compiled with -pie before).
>>> The new patch would however leave more of the magic to the toolchain
>>> and seems more "correct" to me, for whatever that's worth. But it
>>> might have some subtle differences to before, got some testcase
>>> where lacking the -Ur flag made a difference?  
>>
>> I don't know the original intent about passing -Ur to the linker,
>> except maybe to stick to the ld manpage which states that the last
>> partial link command should be given such option.
>>
>> However my understanding is that we don't need it in wrap-link.sh,
>> since the script eventually completes the link stage to produce a
>> fully resolved executable. That implies collecting the ctors/dtors and
>> resolving all references from the partially linked object file anyway.
>>
>> Some testing only passing -r here seems to confirm this assumption
>> with C++ apps; C++ users may want to check this too:
> 
> I just told some C++ power users to give that a try. I am not sure how
> fast the feedback will arrive, i hope in the next two weeks.
> 

Ok, thanks.

-- 
Philippe.

Re: [Xenomai] Won`t build on new Debian Stable

[Philippe Gerum]

On 10/19/2017 06:55 PM, Henning Schild wrote:
> On Thu, 19 Oct 2017 12:03:33 +0200
> Philippe Gerum <rpm@xenomai.org> wrote:
> 
>> On 10/13/2017 01:36 PM, Norbert Lange wrote:
>>> I works, because collect2 (the "compiler driver", which documents
>>> the -r option) now knows about the -r flag, using -Wl,-[U]r would
>>> mean the flags aren't even looked at.
>>> It can then disable functionality that is not supposed to be done at
>>> this point (see gcc/collect2.c, search for 'early_exit'). It might
>>> actually be in conflict with the -Ur option from the comments, but I
>>> don't know what this is trying to solve (the constructor tables
>>> would then be built in the second step?)
>>>
>>> I would prefer the compiler driver knowing about the flags and
>>> correctly dealing with them, instead of replicating this logic in
>>> scripts (and keeping it up to date with this internal logic).  
>>
>> Ack.
>>
>>> Might be that your wrapper script is doing something similarly by
>>> filtering out the arguments for the first step, which might be the
>>> same functionally that is skipped when adding '-r'
>>>
>>> I dont know what the -Ur flag is trying to solve, and the first
>>> patch adding -no-pie is way less likely to change something (given
>>> that I would not have compiled with -pie before).
>>> The new patch would however leave more of the magic to the toolchain
>>> and seems more "correct" to me, for whatever that's worth. But it
>>> might have some subtle differences to before, got some testcase
>>> where lacking the -Ur flag made a difference?  
>>
>> I don't know the original intent about passing -Ur to the linker,
>> except maybe to stick to the ld manpage which states that the last
>> partial link command should be given such option.
>>
>> However my understanding is that we don't need it in wrap-link.sh,
>> since the script eventually completes the link stage to produce a
>> fully resolved executable. That implies collecting the ctors/dtors and
>> resolving all references from the partially linked object file anyway.
>>
>> Some testing only passing -r here seems to confirm this assumption
>> with C++ apps; C++ users may want to check this too:
> 
> I just told some C++ power users to give that a try. I am not sure how
> fast the feedback will arrive, i hope in the next two weeks.
> 
> Henning
> 
>>
>> diff --git a/scripts/wrap-link.sh b/scripts/wrap-link.sh
>> index aab7899..fa83bd5 100755
>> --- a/scripts/wrap-link.sh
>> +++ b/scripts/wrap-link.sh
>> @@ -204,7 +204,7 @@ done
>>
>>  if $stage2; then
>>      $verbose && set -x
>> -    $dryrun $cc -o "$output.tmp" -Wl,-Ur -nostdlib $stage1_args
>> +    $dryrun $cc -o "$output.tmp" -r -nostdlib $stage1_args
>>      $dryrun $cc -o "$output" "$output.tmp" $stage2_args
>>      $dryrun rm -f $output.tmp
>>  else
>>

Any news from the Xenomai/C++ folks regarding this change? I plan to
merge it next week if nobody complains.

-- 
Philippe.

Re: [Xenomai] Won`t build on new Debian Stable

[Jan Kiszka]

On 2017-11-09 10:38, Philippe Gerum wrote:
> On 10/19/2017 06:55 PM, Henning Schild wrote:
>> On Thu, 19 Oct 2017 12:03:33 +0200
>> Philippe Gerum <rpm@xenomai.org> wrote:
>>
>>> On 10/13/2017 01:36 PM, Norbert Lange wrote:
>>>> I works, because collect2 (the "compiler driver", which documents
>>>> the -r option) now knows about the -r flag, using -Wl,-[U]r would
>>>> mean the flags aren't even looked at.
>>>> It can then disable functionality that is not supposed to be done at
>>>> this point (see gcc/collect2.c, search for 'early_exit'). It might
>>>> actually be in conflict with the -Ur option from the comments, but I
>>>> don't know what this is trying to solve (the constructor tables
>>>> would then be built in the second step?)
>>>>
>>>> I would prefer the compiler driver knowing about the flags and
>>>> correctly dealing with them, instead of replicating this logic in
>>>> scripts (and keeping it up to date with this internal logic).  
>>>
>>> Ack.
>>>
>>>> Might be that your wrapper script is doing something similarly by
>>>> filtering out the arguments for the first step, which might be the
>>>> same functionally that is skipped when adding '-r'
>>>>
>>>> I dont know what the -Ur flag is trying to solve, and the first
>>>> patch adding -no-pie is way less likely to change something (given
>>>> that I would not have compiled with -pie before).
>>>> The new patch would however leave more of the magic to the toolchain
>>>> and seems more "correct" to me, for whatever that's worth. But it
>>>> might have some subtle differences to before, got some testcase
>>>> where lacking the -Ur flag made a difference?  
>>>
>>> I don't know the original intent about passing -Ur to the linker,
>>> except maybe to stick to the ld manpage which states that the last
>>> partial link command should be given such option.
>>>
>>> However my understanding is that we don't need it in wrap-link.sh,
>>> since the script eventually completes the link stage to produce a
>>> fully resolved executable. That implies collecting the ctors/dtors and
>>> resolving all references from the partially linked object file anyway.
>>>
>>> Some testing only passing -r here seems to confirm this assumption
>>> with C++ apps; C++ users may want to check this too:
>>
>> I just told some C++ power users to give that a try. I am not sure how
>> fast the feedback will arrive, i hope in the next two weeks.
>>
>> Henning
>>
>>>
>>> diff --git a/scripts/wrap-link.sh b/scripts/wrap-link.sh
>>> index aab7899..fa83bd5 100755
>>> --- a/scripts/wrap-link.sh
>>> +++ b/scripts/wrap-link.sh
>>> @@ -204,7 +204,7 @@ done
>>>
>>>  if $stage2; then
>>>      $verbose && set -x
>>> -    $dryrun $cc -o "$output.tmp" -Wl,-Ur -nostdlib $stage1_args
>>> +    $dryrun $cc -o "$output.tmp" -r -nostdlib $stage1_args
>>>      $dryrun $cc -o "$output" "$output.tmp" $stage2_args
>>>      $dryrun rm -f $output.tmp
>>>  else
>>>
> 
> Any news from the Xenomai/C++ folks regarding this change? I plan to
> merge it next week if nobody complains.
> 

(Henning is on vacation) What I heard from our folks who could test this
extensively is that they are unfortunately busy right now. So, if you
want to merge, you should probably not wait for this feedback.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux