Doubts using the precompiled binaries

[Janne Blomqvist]

On Wed, Apr 26, 2017 at 2:13 AM, Manfred Schwarb <manfred99@gmx.ch> wrote:
> Am 26.04.2017 um 00:21 schrieb Manfred Schwarb:
>> Am 25.04.2017 um 20:30 schrieb marco restelli:
>>> 2) Trying to do static linking with "-static" I get the error
>>>
>>> <local-installation-path>/bin/../lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../lib64/libgfortran.a(unix.o):
>>> In function `tempfile':
>>> /tmp/gcc-6.3.0-build/x86_64-pc-linux-gnu/libgfortran/../../../gcc-6.3.0-source/gcc-6.3.0/libgfortran/io/unix.c:1208:
>>> undefined reference to `__secure_getenv'
>>> collect2: error: ld returned 1 exit status
>>>
>>
>> Hmm, I do see it, too. No idea. I will investigate, seems to be quite a mess.
>> If someone has a clue, I would appreciate it.
>>
>> The build system has binutils-2.25, as I got troubles building gfortran
>> with older binutils. I don't know if this has something to do with it.
>>
>
> Seems to have nothing to do with binutils.
> glibc <2.17 has __secure_getenv.
> glibc >=2.17 has __secure_getenv and secure_getenv, but you can not link against __secure_getenv.
> So if you compile libgfortran on a system with old glibc, you
> can't use it for static compilation on a system with new glibc.
>
> Baah.
> So only solution seems to jump to a newer glibc?
>
> Would this be acceptable? Anyone?

Agh. I introduced the usage of __secure_getenv, and later on when
secure_getenv was made an official exported symbol I changed the
configury per https://sourceware.org/glibc/wiki/Tips_and_Tricks/secure_getenv

Googling I find a few bug reports that seem related to usage of
__secure_getenv and static linking:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701385

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708061

https://github.com/Linuxbrew/legacy-linuxbrew/issues/135

The problem seems to be that __secure_getenv is NOT present in the
static glibc (libc.a) >= 2.17, and thus if libgfortran has been built
against an older version of glibc where that one exists you get
linking failures when trying to link against a newer libc.a.

The idea of secure_getenv is to protect against environment variable
injection attacks against programs running with superuser privileges.
Nice to have, but in the end probably not terribly important for the
typical usecases of gfortran. So I suggest to remove the usage of
__secure_getenv, and only use the official secure_getenv if available.
Is that Ok for everyone?

-- 
Janne Blomqvist