Created attachment 397712 [details, diff] lsof-4.87 remove glibc check Assign this to blueness@gentoo.org who maintains the musl branch sys-process/lsof-4.87 does not compile on musl because a patch to lsof.h adds "#include <netinet/tcp.h>". Later in lsof.h file there is an include on dlsof.h, which itself has an include macro check on either netinet/tcp.h OR linux/tcp.h depending on whether glibc is found. Since glibc obviously is not found on musl, gcc tries to include linux/tcp.h then causing an "redefinition of struct" error in dfile.c. Trying to add the same include macro check on lsof.h fails because dsock.h, which includes lsof.h, uses enums not available in linux/tcp.h, but which are available in both glibc, musl and uclibc. Since there is no way the source code can compile with just linux/tcp.h, because of the missing enum, I have attached a patch which removes the check on glibc and always include netinet/tcp.h.
Created attachment 397714 [details] lsof-4.87 build log
Created attachment 397716 [details, diff] lsof-4.87 ebuild patch
Created attachment 397718 [details] emerge --info
(In reply to Cato Auestad from comment #3) > Created attachment 397718 [details] > emerge --info Okay I've add this to the overlay. We should try to get this in upstream. Can you see if you can figure out how?
Seems like lsof is maintained by a single individual, I'll get in touch and try to work something out.
Note that this bug exists on version 4.88 as well.
After discussions with the author he suggested that a better fix for this would be to add a test to Configure and a pre-processor test to dlsof.h which includes netinet/tcp.h if the Configure-test can't find the enum containing TCP_ESTABLISHED (and the like). He have updated the tarball on the source server and changed version to 4.89B. You can find the tarball here: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/NEW/lsof_4.89B.linux.tar.bz2 I have created an ebuild for 4.89B (just a modified copy of 4.87) and done a successfull install on hardened/musl. Since this package is not musl specific I guess this bug should probably be reassigned to the maintainer of lsof so he can update this package "globally"? For convenience I have added the following attachments to this bug: * A copy of the modified ebuild I created * A diff highlighting the changes I made to the 4.87 ebuild * A diff highlighting the changes the author made to Configure and dlsof.h Please advice of next steps to resolve this bug
Created attachment 397818 [details] diff showing author modifications to Configure/dlsof.h
Created attachment 397820 [details] Sample of lsof 4.89B ebuild script
Created attachment 397822 [details] diff showing modifications between 4.87 ebuild and 4.89 ebuild
(In reply to Cato Auestad from comment #8) > Created attachment 397818 [details] > diff showing author modifications to Configure/dlsof.h Is there a url to this patch? ie where's the repo showing the commit.
(In reply to Anthony Basile from comment #11) > (In reply to Cato Auestad from comment #8) > > Created attachment 397818 [details] > > diff showing author modifications to Configure/dlsof.h > > Is there a url to this patch? ie where's the repo showing the commit. I checked with the author after your last comment and there is no URL to a repository for lsof. The source code for lsof is in a non-public repository. You can see the change by downloading 4.89B and do a diff on the previous version. As a temporary solution I could make a patch to 4.87 which implements the authors changes (related to the issue with netinet/tcp.h) in 4.89B on the musl overlay. But I imagine since this really is a new version we should rather stay up to date with upstream than patch older versions ourselves.
(In reply to Cato Auestad from comment #12) > (In reply to Anthony Basile from comment #11) > > (In reply to Cato Auestad from comment #8) > > > Created attachment 397818 [details] > > > diff showing author modifications to Configure/dlsof.h > > > > Is there a url to this patch? ie where's the repo showing the commit. > > I checked with the author after your last comment and there is no URL to a > repository for lsof. The source code for lsof is in a non-public repository. > > You can see the change by downloading 4.89B and do a diff on the previous > version. As a temporary solution I could make a patch to 4.87 which > implements the authors changes (related to the issue with netinet/tcp.h) in > 4.89B on the musl overlay. But I imagine since this really is a new version > we should rather stay up to date with upstream than patch older versions > ourselves. The reason I ask is that this is not my package, its maintained by base-system. However, I would backport the fix if it were already upstream.
(In reply to Anthony Basile from comment #13) > (In reply to Cato Auestad from comment #12) > > (In reply to Anthony Basile from comment #11) > > > (In reply to Cato Auestad from comment #8) > > > > Created attachment 397818 [details] > > > > diff showing author modifications to Configure/dlsof.h > > > > > > Is there a url to this patch? ie where's the repo showing the commit. > > > > I checked with the author after your last comment and there is no URL to a > > repository for lsof. The source code for lsof is in a non-public repository. > > > > You can see the change by downloading 4.89B and do a diff on the previous > > version. As a temporary solution I could make a patch to 4.87 which > > implements the authors changes (related to the issue with netinet/tcp.h) in > > 4.89B on the musl overlay. But I imagine since this really is a new version > > we should rather stay up to date with upstream than patch older versions > > ourselves. > > The reason I ask is that this is not my package, its maintained by > base-system. However, I would backport the fix if it were already upstream. As I mentioned on IRC, I guess you would either have to do a diff and patch on the 4.87 and 4.89B's Configure and dlsof.h to get it working on musl, or wait till 4.89 is out of beta and implemented by base-system. If there is anything else I can contribute with for resolution of this bug, let me know.
(In reply to Cato Auestad from comment #14) lets just wait for the 4.89 final release
4.89 is stable, so there's nothing left here