Doubts using the precompiled binaries

[Manfred Schwarb]

Am 26.04.2017 um 09:09 schrieb 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?
> 

That would work for me, I could apply such a patch to older sources before
building then. But I'm not allowed to vote, of course.

Thanks,
Manfred