[ITP, take 2] Re: [ITP] libelf

[Yaakov (Cygwin/X)]

On 20/12/2009 15:07, Dave Korn wrote:
>    Thanks, I don't know much about the detailed usage of quite a few of the
> cygport variables.  (There isn't any other significant documentation beyond
> the contents of /usr/share/doc/cygport/, is there?)

There is actually some work on API documentation in SVN trunk, but it's 
still far from complete.

The other thing I should point out is that USE_DESTDIR defaults to 1.

>    I used --disable-compat because I thought it would keep things tidy to tuck
> them away in their own subdir and that pkg-config would take care of the rest,
> but if there are packages that won't find the headers without it, it's not
> worth doing, so I removed it.

Actually, you need to add an explicit --enable-compat, otherwise 
whenever you need to roll the next version/release, it will see <gelf.h> 
and <libelf.h> present (from this release) and default to DO_COMPAT=no 
to avoid overwriting them (for fear they are libc headers).

>    (There's also three new imports added, but anyway:) I couldn't figure out
> how to solve that in the cygport framework, so I just let it go.  The original
> file is CRLF, I edit the file and make sure to preserve CRLFs and get a
> .src.patch with just a few lines difference, great; but as soon as you rebuild
> it from source, patch converts the line endings of the entire file to LF when
> it applies the diff (as it's running in text mode), and so the regenerated
> package has the whole file looking different.  Is there a fix?  I just figured
> it was no real harm and to live with it.

The easiest way to deal with this is to take the .src.patch (after 
fixing the line-ending differences) and create one or more standalone 
patches:

0.8.13-DESTDIR.patch
0.8.13-symbol-imports.patch
0.8.13-shlib-cygwin.patch
etc....

Then add these basenames to PATCH_URI.  (This is how I manage all my 
patches nowadays.)  This avoids the problem because the patch is applied 
to origsrc/ before it is copied into src/.  Also this way, you don't 
also have to rename the patch for every version even if the patch itself 
still applies as is with the new version (as it often does).

>    Say, I checked but didn't find that!  http://sourceware.org/cygwinports/ ->
> "A list of currently available packages" ->
> ftp://sourceware.org/pub/cygwinports/portslist-2.txt ->  no mention of libelf!

That's because the list reflects the packages currently available with 
setup.exe, and I only added libelf to SVN after the last upload.  I 
suppose SVN could also use some sort of TOC.

>    Anyway, we did more or less the same things re. shared libs and -lintl, and
> I decided to make DESTDIR work rather than disable it because I know that
> better than I do how to use the do* macros.

Those are just differences in style.  You could also do "cyginstall 
instroot=${D}" instead of the DESTDIR patch if you prefer.

>    Why didn't you get problems when it detected the cygwin elf.h?  The way it
> worked out for me, when libelf noticed I had /usr/include/elf.h, the installed
> headers deferred to that rather than using libelf's own elf_repl.h, causing
> gcc bootstrap to fail for lack of a definition of SHN_XINDEX.  (Hence why I
> adjusted the autoconf test for elf.h to use it.)

Because I didn't try building gcc with my libelf. :-)  But if gcc needs 
SHN_XINDEX, why not just add the #define to our <sys/elf_common.h>?

>    Anyway I've updated it with all your suggestions, mind taking a second look?
>   All packages at the same URLs as before.

In libelf0/setup.hint, libgcc1 is missing from requires:.

With that and an explicit --enable-compat to cygconf, GTG.

HTH,


Yaakov