Doubts using the precompiled binaries

[Janne Blomqvist]

On Wed, Apr 26, 2017 at 6:21 PM, Manfred Schwarb <manfred99@gmx.ch> wrote:
> 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.

I just committed https://gcc.gnu.org/r247927 to trunk, can you apply
it to your tree and see whether it works (my gfortran dev machine has
glibc 2.23 so I can't see whether the weakref trick actually works..)?

Thanks.

>
> Thanks,
> Manfred
>
>



-- 
Janne Blomqvist