[hurd,commited] hurd: fix build with -fstack-protector-strong libmachuser and libhurduser also need stack_chk_fail_local and they do not link against libc_nonshared. * mach/stack_chk_fail_local.c: New file. * hurd/stack_chk_fail_local.c: New file. * mach/

On Sun, 27 Aug 2017, Samuel Thibault wrote:

> +	* mach/Versions (GLIBC_2.4): Add __stack_chk_fail.
> +	* hurd/Versions (GLIBC_2.4): Add __stack_chk_fail.

These changes look suspicious.  debug/Versions already exports 
__stack_chk_fail from libc at version GLIBC_2.4, so I'd expect those new 
Versions entries to have no effect (meaning they should be removed as 
useless).  And any export added at the symbol version for a past release 
needs a more detailed justification given, presumably along the lines of 
"unmodified glibc 2.4 and later releases have not built or worked for 
Hurd, so the de facto GLIBC_2.4 ABI is determined by the binaries people 
have actually been using, presumably Debian, which include that symbol at 
that version (and, hopefully, have done so ever since Debian packages of 
2.4)".

(The missing semicolon at the end of the new Versions entries is also 
suspicious; at least, contrary to the syntax normally used in these 
files.)
  

Hello,

Joseph Myers, on lun. 28 août 2017 11:44:56 +0000, wrote:
> On Sun, 27 Aug 2017, Samuel Thibault wrote:
> > +	* mach/Versions (GLIBC_2.4): Add __stack_chk_fail.
> > +	* hurd/Versions (GLIBC_2.4): Add __stack_chk_fail.
> 
> These changes look suspicious.  debug/Versions already exports 
> __stack_chk_fail from libc at version GLIBC_2.4, so I'd expect those new 
> Versions entries to have no effect

Ok, I had misunderstood the use of the similar versions added above
(__mach_msg, __mach_msg_overwrite, etc. which are defined by mach
itself)

> (The missing semicolon at the end of the new Versions entries is also 
> suspicious; at least, contrary to the syntax normally used in these 
> files.)

Indeed. If only I could find time to make master working, I'd be able to
work with it instead of keeping a cumbersome flow of patches between 3
differents repos :/

Thanks for the checks,
Samuel
  

On Mon, 28 Aug 2017, Samuel Thibault wrote:

> Hello,
> 
> Joseph Myers, on lun. 28 août 2017 11:44:56 +0000, wrote:
> > On Sun, 27 Aug 2017, Samuel Thibault wrote:
> > > +	* mach/Versions (GLIBC_2.4): Add __stack_chk_fail.
> > > +	* hurd/Versions (GLIBC_2.4): Add __stack_chk_fail.
> > 
> > These changes look suspicious.  debug/Versions already exports 
> > __stack_chk_fail from libc at version GLIBC_2.4, so I'd expect those new 
> > Versions entries to have no effect
> 
> Ok, I had misunderstood the use of the similar versions added above
> (__mach_msg, __mach_msg_overwrite, etc. which are defined by mach
> itself)

Well, I'm not familiar with any Mach-specific/Hurd-specific symbol 
versioning issues.  But as far as I know the following apply generally to 
all ports:

* The contents of a particular public symbol version should be fixed at 
the time of the corresponding release (subject to any questions around 
ports that were completely broken at the time of the release so the 
sources people actually used were something else).

* Only one visible (in a subdirectory used by make) Versions entry for a 
given (library, symbol, version) triple should be needed.  So just the 
debug/Versions entry for __stack_chk_fail at version GLIBC_2.4 in libc.

* If a symbol is added only for internal use between glibc's own 
libraries, not for use by external programs or libraries, it should have 
version GLIBC_PRIVATE.  The contents of GLIBC_PRIVATE *can* change 
arbitrarily between releases (although adding symbols in bug fixes on 
release branches is still problematic, because of the effects on running 
programs when you upgrade a live system and the running program later 
tries to load another glibc library, which now expects a new GLIBC_PRIVATE 
symbol).

* The *.abilist test baselines can be used to verify that past symbol 
versions don't get changed unintentionally.  Hurd of course needs such 
baselines added, which you could verify against existing binaries of 
various different versions to make sure they reflect what the ABI of 
different versions was in practice.
  

Joseph Myers, on lun. 28 août 2017 12:42:29 +0000, wrote:
> * The contents of a particular public symbol version should be fixed at 
> the time of the corresponding release

Sure.

> * Only one visible (in a subdirectory used by make) Versions entry for a 
> given (library, symbol, version) triple should be needed.

Yes, that's what I had misunderstood in the mach/ RPC-needed symbols
case, I thought it was needed to make RPCs access them.

> * If a symbol is added only for internal use between glibc's own 
> libraries, not for use by external programs or libraries, it should have 
> version GLIBC_PRIVATE.

Right.

> * The *.abilist test baselines can be used to verify that past symbol 
> versions don't get changed unintentionally.  Hurd of course needs such 
> baselines added,

We miss that indeed.

Samuel