Re: RFS: libhugetlbfs
Sorry for the long delay in responding. When I posted first, I thought
things would be quiet for a while but I got bogged down fixing bugs in
kernel 2.6.24-rc8. It curtailed free time :/ It's not much better now
but I thought I would kick it once before heading to FOSDEM.
On (15/01/08 00:53), Cyril Brulebois didst pronounce:
> On 14/01/2008, Mel Gorman wrote:
> > The documentation is pretty decent but there is a lot of it.
>
> Rome wasn't built in a day? ;-)
>
Indeed not. I expect the documentation will sink in eventually.
> > > W: libhugetlbfs: shlib-with-executable-stack usr/lib/libhugetlbfs.so
> >
> > I give up, whats the right way of fixing this? Searching around says I
> > should be able to pass -Wa,--execstack via the compiler to the
> > assembler but it does not appear to be supporting by the binutils in
> > Debian testing. This is very likely a build issue in the upstream
> > package as well.
>
> Actually, I don't know. My first guess would be to ask upstream whether:
> it's wanted, and if so, if it's needed. Either they have to fix it, or
> you'll have to investigate how to deal with it.
>
They weren't aware of the issue. For the moment, I'm going to see what
is required to make things work for Debian in 1.2 and then forward-port
that to the development version. When it releases, I'll update the
Debian package to match.
> For those who didn't build this package, lintian outputs:
> | N: The listed shared libraries declares the stack as executable.
> | N:
> | N: Executable stack is usualy an error as it is only needed if the code
> | N: contains GCC trampolines or similar constructs which uses code on the
> | N: stack. One possible source for false positives are object files built
> | N: from assembler files which don't define a proper .note.GNU-stack
> | N: section.
>
> And there are assembler files:
> | $ find -name '*.S'
> | ./elf_i386.S
> | ./elf32ppclinux.S
> | ./elf64ppc.S
> | ./elf_x86_64.S
>
> Looks to me that it probably will only work on: i386, amd64, powerpc,
i386, amd64 and ppc64 actually. The naming is confusing and while it
might work on 32 bit ppc, I know it has not been tested in a long time.
I updated the Architecture in the control file to read
Architecture: i386 amd64 ppc64
> you should ask upstream if support for more architecture is planned, and
> eventually change ???Architecture: any??? to an explicit list of supported
> architectures.
>
No wider support is planned. IA-64 support is a remote possibility but I
know it is not high on the list of priorities.
> Anyway, asking upstream to double-check that .note.GNU-stack thing
> should help.
>
> > I removed the shlibs file as it should have been possible to use
> > dh_makeshlibs. The rules file now calls it but it's still not
> > generating the shlibs file correctly (-v shows the script to be doing
> > nothing). The lintian error is
> >
> > E: libhugetlbfs: no-shlibs-control-file usr/lib/libhugetlbfs.so
> > N:
> > N: Although the package includes a shared library, the package does not
> > N: have a shlibs control file. If this is intentional, please override
> > N: this error.
> > N:
> > N: Refer to Policy Manual, section 8.6 for details.
>
> AFAICT, dh_makeshlibs might work better if you had proper library
> versioning (using SONAME).
>
Tracking the development version at the moment, I know the next major
release will be significantly different to what the current version
does. While I can fix the stack and Makefile fixes backported, I think
adding proper versioning just for debian would be a mistake. The proper
thing is to fix it upstream and do a another package release later. This
would keep the Debian version of libhugetlbfs consistent with whats in
RHEL, Fedora and SuSE.
This would impact proper versioning in this package though but as future
versions of the library are likely to be incompatible anyway, it likely
isn't a problem
It's worth noting that the main function of hte library is to provide
functionality with LD_PRELOAD or during application start-up time. There
is no expectation for any API to be called.
> > I think that is a global override which doesn't feel like the right
> > thing to be doing. I suspect I'm missing something in the control file
> > or some other file is missing that tells dh_makeshlibs what to do.
>
> That would rather be ???dh_makeshlibs -V??? (but that is *only* to give you
> an idea of what you need to do, and not the final word on this. -V
> without parameters is dangerous and error-prone). But again, please take
> that to upstream and ask them for proper versioning (in case I didn't
> say that in my first mail, that would permit having a foo application
> linked against libhugetlbfs1 to keep on working while having another bar
> application linked against libhugetlbfs2, so that upgrades are as smooth
> as possible).
>
I'll be kicking upstream but it won't happen quickly. The version of
libhugetlbfs that will have versioning assuming I kick hard enough will
be functionally quite different from this as well.
> > I updated the version to distinguish between initial release and when
> > feedback gets incorporated. This "hides" the lintian error. I'll need
> > to create an ITP bug before the end of this.
>
> Once you've asked upstream all these questions, you have plenty of time
> to open this ITP bug. ;)
heh
> >
> > The upstream versioning needs work. I'll need to kick that
> > independently of this package or should I trying to add versioning
> > into the Debian version of the library?
>
> Please ask upstream first. That might be very painful to maintain a
> different versioning than upstream's. Particularly if that's a new
> exercise for you.
>
After chatting with them, I think the amount of upheaval would be a lot
of work with little benefit. It makes more sense just to fix the next
release but that will be a long time away, functionally different etc.
> > Thanks for the feedback, it's appreciated. Pointers on how to close
> > the other two lintian errors would be welcome. Trawling around the
> > policy documents and other packages did not reveal the answers but no
> > doubt I'm missing something obvious.
>
> It's not obvious, rather upstream have to do some job before you can
> progressively come to a (one of the possible) conclusion(s). As it's
> often the case: patience is the key.
>
> > The latest dsc file is at
> > http://mentors.debian.net/debian/pool/main/l/libhugetlbfs/libhugetlbfs_1.2-2.dsc.
>
> Another remark while I'm at it, your package isn't really clean, since
> the following files appear in the source package diff (diff.gz):
> | $ zcat ../libhugetlbfs_1.2-2.diff.gz | lsdiff | grep -v /debian/
> | libhugetlbfs-1.2/Makefile
> | libhugetlbfs-1.2/libhugetlbfs_write_dirs_installs
> | libhugetlbfs-1.2/strace.out
> | libhugetlbfs-1.2/version.h
>
> If you're applying modifications to upstream's files, it's best practice
> to use a patch management system (like dpatch or quilt) to do so. If
I'm moving the patches into quilt. It makes it easier for punting the
patches upstream as well.
> some of them are files that are just build logs/traces and so on, you
> could just remove them in the clean target. dpkg-source won't complain
> (just warn) about their deletion, and they won't appear in the source
> diff anymore.
>
> Looking at them:
> - libhugetlbfs-1.2/libhugetlbfs_write_dirs_installs might just go under
> debian, that'd be cleaner.
moved
> - Makefile might deserve a dpatch/quilt patch.
agreed
> - strace.out might just disappear.
An accidental inclusion.
> - version.h could go along Makefile (in the same patch).
>
I move it.
> I know you're still struggling with the build system, so that might be a
> burden to handle a patch management system.
Nah, I regularly use git and quilt for kernel work - it's not a problem.
> But in the long run, once
> you've sorted out versioning and stack troubles with upstream, switching
> to a patch management system will help you. Maybe not in the few next
> days or weeks, but you'll see for yourself. ;-)
>
For sure. Thanks for the advice and sorry again for the incredible
tardiness.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
Reply to: