Re: pending patches

[Ulf Hermann <ulf.hermann@qt.io>]

> - 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