pending patches

pending patches

[Mark Wielaard]

Hi Ulf,

Here are some short comments on the pending patches that I would like to
deal with after the 0.169 release. I believe what we have now on master
is a good set of fixes that look OK on Fedora 25/RHEL7 x86_64. I'll run
some tests on other distros and supported Fedora/RHEL architectures in
the next days. And if no show-stoppers pop up I'll like to do a release
on Friday. Then next week we return to these patches.

- Add gnulub modules to replace missing libc functionality.
  The big one. I am surprised that actually made it to the list.
  I haven't tried it out yet, but it looks basically sane.
  What is missing is a description/script to run for updates.
  I have to add something like that for some other special files
  (elf.h, po files) too so anybody can easily run it before a
  release.

- Drop handrolled or #ifdef'ed libc replacement.
  Right, should go in right after the above.

- Check for -z,defs, -z,relro, -fPIC, -fPIE before using them
  There are actually two versions, I haven't looked yet how they differ.
- Check if gcc complains about __attribute__ (visibility(..))
- Disable symbol versioning if .symver doesn't work
- Check if rpath is supported before setting it

In all of the above cases checking for support is a good thing.
But I am a little hesitant about automatically disabling support.
For example our binary compatibility depends on having symbol versioning
support. It seems bad to "silently" break that. And without rpath
support backends aren't found and stuff will mysteriously break. So I
think I prefer configure to error out and have an explicit override
option someone would have to use indicating they are building a broken
elfutils.

- Check if we need -lintl for linking gettext
  This looks OK, but I don't know much about gettext support.

- Generalize library names
  This looks like a nice cleanup, but I don't know anything about how
  non-gnu/linux systems do library sonames (I also use a local hack
  sometimes to explicitly set a different version that I should upstream
  myself).

- Check native binary format
  Yes, running self-test/checks on non-ELF binaries is not going to
  work.

Cheers,

Mark

Re: pending patches

[Ulf Hermann]

> - Check for -z,defs, -z,relro, -fPIC, -fPIE before using them
>   There are actually two versions, I haven't looked yet how they differ.
> - Check if gcc complains about __attribute__ (visibility(..))
> - Disable symbol versioning if .symver doesn't work
> - Check if rpath is supported before setting it
> 
> In all of the above cases checking for support is a good thing.
> But I am a little hesitant about automatically disabling support.
> For example our binary compatibility depends on having symbol versioning
> support. It seems bad to "silently" break that. And without rpath
> support backends aren't found and stuff will mysteriously break. So I
> think I prefer configure to error out and have an explicit override
> option someone would have to use indicating they are building a broken
> elfutils.

That can be done. I will post new versions of the patches to add a configure switch.

My problem right now is that I have about 50 more patches pending locally and I will be gone from May 12th to sometime in August. So, I probably won't manage to post and fix all of them here before autumn. Yet, I still need them for the Qt Creator (and perfparser) 4.4 release, for which the feature freeze will happen when I'm gone.

To deal with this, right now I have a fork of elfutils at http://code.qt.io/cgit/qt-creator/elfutils.git/ which receives the patches before they get here. This is not great and I want to merge it eventually, but I can't clone myself.

> - Check if we need -lintl for linking gettext
>   This looks OK, but I don't know much about gettext support.

It's just that mingw doesn't really have a libc and msvcrt.dll doesn't have gettext. So we need to link libintl.a or libintl.dll (as provided by mingw) separately.

> - Generalize library names
>   This looks like a nice cleanup, but I don't know anything about how
>   non-gnu/linux systems do library sonames (I also use a local hack
>   sometimes to explicitly set a different version that I should upstream
>   myself).

Well, not at all. It's called dll hell :(. The patch provides binaries with the version encoded into the file name, which can make things somewhat better. However, as dw.dll (and dw1.dll and dw-0.168.dll) link against plain elf.dll, extra hackery is required if you want to use the files with versions encoded. Also you cannot do "-lelf" then, but rather "-lelf1".

Ulf

Re: pending patches

[Ulf Hermann]

> - Check for -z,defs, -z,relro, -fPIC, -fPIE before using them
>   There are actually two versions, I haven't looked yet how they differ.

There was a typo in tests/Makefile.am which I fixed in the second version. This change actually doesn't disable symbol versioning or rpath. It just conditionally disables PIC, PIE, making sections read-only after relocations, and the assertion that all symbols are defined. This is because on some platforms these are implicitly guaranteed or not applicable and gcc will complain about the "redundant" flags.

> - Check if gcc complains about __attribute__ (visibility(..))

This also doesn't disable anything critical. It just makes all symbols visible if the check fails. On some platforms the visibility of symbols cannot be handled with attributes.

> - Disable symbol versioning if .symver doesn't work

Actually there already is a configure switch to disable symbol versioning. We can use that ...

cheers,
Ulf

Re: pending patches

[Mark Wielaard]

Hi Ulf,

On Wed, 2017-05-03 at 13:26 +0200, Ulf Hermann wrote:
> My problem right now is that I have about 50 more patches pending
> locally and I will be gone from May 12th to sometime in August. So, I
> probably won't manage to post and fix all of them here before autumn.
> Yet, I still need them for the Qt Creator (and perfparser) 4.4
> release, for which the feature freeze will happen when I'm gone.

Sorry about that. Seems I planned the 0.169 release somewhat
inconvenient for you. But I don't think we would have many more patches
in if we had waited a week.

> To deal with this, right now I have a fork of elfutils at
> http://code.qt.io/cgit/qt-creator/elfutils.git/ which receives the
> patches before they get here. This is not great and I want to merge it
> eventually, but I can't clone myself.

It looks like you have a nice setup already. But if it would be helpful
to have a user branch on sourceware.org then please follow the steps in
CONTRIBUTING on how to become a committer. Then even if we don't
integrate all your patches in master it will look more like an "official
fork" to support a Windows build.

Cheers,

Mark