Re: [PATCH v3 2/2] Default to --with-default-link=no (bug 25812)

[Florian Weimer <fweimer@redhat.com>]

* Siddhesh Poyarekar:

>> diff --git a/INSTALL b/INSTALL
>> index 63c022d6b9..de150f66eb 100644
>> --- a/INSTALL
>> +++ b/INSTALL
>> @@ -90,6 +90,12 @@ if 'CFLAGS' is specified it must enable optimization.  For example:
>>        library will still be usable, but functionality may be lost--for
>>        example, you can't build a shared libc with old binutils.
>>   +'--with-default-link=FLAG'
>> +     With '--with-default-link=yes', the GNU C Library does not use a
>> +     custom linker scipt for linking its individual shared objects.  The
>> +     default for FLAG is the opposite, 'no', because the custom linker
>> +     script is needed for full RELRO protection.
>> +
>
> Andreas' comments still apply here I think, i.e. fix the "scipt" type
> and rephrase so that it's clearer that the option controls the library 
> build process and not the library itself.

I thought I had fixed this.  What about this?

'--with-default-link=FLAG'
     With '--with-default-link=yes', the build system does not use a
     custom linker script for linking shared objects.  The default for
     FLAG is the opposite, 'no', because the custom linker script is
     needed for full RELRO protection.

> Does it make sense to make this --disable-custom-link or
> --enable-default-link instead, since the option is binary?  The --with 
> prefix is typically for richer options, e.g. paths.  Suggest something
> like this:
>
> --disable-custom-link
>     Don't use a custom linker script to build the GNU C Library,
>     preferring the static linker's default script instead.  The custom
>     linker script is needed for full RELRO protection.

I want to backport this, and distributions are already using this
option, so I prefer not to make changes here.

>> diff --git a/elf/tst-relro-symbols.py b/elf/tst-relro-symbols.py
>> new file mode 100644
>> index 0000000000..368ea3349f
>> --- /dev/null
>> +++ b/elf/tst-relro-symbols.py
>> @@ -0,0 +1,137 @@

>> +# Make available glibc Python modules.
>> +sys.path.append(os.path.join(
>> +    os.path.dirname(os.path.realpath(__file__)), os.path.pardir, 'scripts'))
>
> I wonder if we should put this in the python environment for all glibc
> python scripts.  Only a soft suggestion though since this is just the 
> first module usage.  Maybe as and when we port other such tests to
> this module we should rethink this.

We set PYTHONPATH in the makefiles in many cases.  I did this mostly for
development.

Thanks,
Florian