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