I was one of the ones scouring bugzilla for the solution being unable to emerge a few packages with the stat64/lstat64 error, figured after a while that it was probably a musl error rather then gcc error so I scoured and got some sources
https://wiki.gentoo.org/wiki/Musl_porti ... pread64.29
original source:https://musl.libc.org/releases.html
The solution gentoo wiki states is to edit the ebuild of the specified package, that leads to the problem that you have to edit the ebuild on every update, better yet it would be wiser and more consistent to make an env entry like so viewtopic-t-1158069-start-0.html, on said example the flag "-mno-avx2" is used you just have to replace it with the given "-D_LARGEFILE64_SOURCE" flag from the wiki, name your file something appropriate like /etc/portage/env/stat64_musl and then just append your packages in package.env following the example from the link above.
PS anyone willing to tell me how to use [topic][post][bug] and [url] tags I be greatful
Solving "undefined/unresolved stat64/lstat64"
Message
1. You can and should use patches, not manually edit on each install. You can do this even without a proper fix by patching in #define _LARGEFILE64_SOURCE or so. But that's a workaround and the env thing you mention is better for local workarounds.
2. That flag you mention will stop working in a newer musl release, as explained on the tracker bug (bug 903611)
I've just updated the wiki page to explain this better.
2. That flag you mention will stop working in a newer musl release, as explained on the tracker bug (bug 903611)
I've just updated the wiki page to explain this better.
Getting a few replies back I would like to add a few things from my perspective as I made this post
Adding the fact that this workaround will stop working in future versions didn't cross my mind as I added the sources and was expecting people to read them, you can see why I didn't edit the wiki myself now
jokes aside about my inability to think around other peoples mindset, some "bugs" related to stat64 and lstat64 have been around in bugzilla for months, in fact a bugzilla post related to libselinux was the reason I went to find a workaround myself, it is a common understanding everyone has that software will continue to evolve and change even though software developers and in this case maintainers will fall behind, in my system's case musl/hardened/selinux is in an experiamental phase, I cannot force maintainers at gunpoint to keep my system packages up and functional, and even though the changing the code itself wouldn't be generally that hard for someone with the skills to do so the general populace does not have those skills most of the time, thus with this as an open letter to any future musl maintainer in gentoo I would like to ask for the possibility of a "lfs64" use flag, so the appropriate patches can be applied to keep the -D_LARGEFILES64_SOURCE until musl profiles are out of the dev and exp phases, my reasoning is simple, it is better to have temporary bloat and have a working system and maintain musl rather then waiting for maintainers to double-check all the packages for a few weeks to months
nevertheless thank you grknight and sam_ for your input,especially sam_ for updating the wiki
on another note this is not a rant but a request irrelevant of the original post, I understand sometimes it would be better to put my money where my mouth is and help out, regardless of my abysmal C skills I have no idea how ebuild development works, do I need the gentoo-dev use flag active on portage? do I prevent portage from fetching and wipeing my ebuild edits or make an overlay and test my builds there like the Basic guide on writeing Gentoo Ebuilds wiki says? No seriously no sarcasm or arrogance in my words at all, I haven't used gentoo for more then 12 months tops and most of that time my system was stable becuase I had a stable glibc/hardened system so thinks like bugs never crossed paths with me it is just that wikis are edited by so many people that sometimes they feel inconsistent to look for information and I wouldn't be able to even know where to start even when I'm thinking "I should be able to fix this myself", so yeah if you see this please DO give me a link or two on how gentoo package development and patching USUALLY works, I know how to make the patches from the orig.c and patches.c files themselves and how place them in etc portage patches but thats about it, dunno where to look for the source either, do I find a tar extract it patch then tar it again and have portage handle installation and receive an seccess or error? ebuilds with SRC_URI, can I pause the process edit the files and continue, I really do not know how any of that works, heck even if you tell me that the information I am looking for is in man portage or man ebuild I'd be dumbfounded
Adding the fact that this workaround will stop working in future versions didn't cross my mind as I added the sources and was expecting people to read them, you can see why I didn't edit the wiki myself now
jokes aside about my inability to think around other peoples mindset, some "bugs" related to stat64 and lstat64 have been around in bugzilla for months, in fact a bugzilla post related to libselinux was the reason I went to find a workaround myself, it is a common understanding everyone has that software will continue to evolve and change even though software developers and in this case maintainers will fall behind, in my system's case musl/hardened/selinux is in an experiamental phase, I cannot force maintainers at gunpoint to keep my system packages up and functional, and even though the changing the code itself wouldn't be generally that hard for someone with the skills to do so the general populace does not have those skills most of the time, thus with this as an open letter to any future musl maintainer in gentoo I would like to ask for the possibility of a "lfs64" use flag, so the appropriate patches can be applied to keep the -D_LARGEFILES64_SOURCE until musl profiles are out of the dev and exp phases, my reasoning is simple, it is better to have temporary bloat and have a working system and maintain musl rather then waiting for maintainers to double-check all the packages for a few weeks to months
nevertheless thank you grknight and sam_ for your input,especially sam_ for updating the wiki
on another note this is not a rant but a request irrelevant of the original post, I understand sometimes it would be better to put my money where my mouth is and help out, regardless of my abysmal C skills I have no idea how ebuild development works, do I need the gentoo-dev use flag active on portage? do I prevent portage from fetching and wipeing my ebuild edits or make an overlay and test my builds there like the Basic guide on writeing Gentoo Ebuilds wiki says? No seriously no sarcasm or arrogance in my words at all, I haven't used gentoo for more then 12 months tops and most of that time my system was stable becuase I had a stable glibc/hardened system so thinks like bugs never crossed paths with me it is just that wikis are edited by so many people that sometimes they feel inconsistent to look for information and I wouldn't be able to even know where to start even when I'm thinking "I should be able to fix this myself", so yeah if you see this please DO give me a link or two on how gentoo package development and patching USUALLY works, I know how to make the patches from the orig.c and patches.c files themselves and how place them in etc portage patches but thats about it, dunno where to look for the source either, do I find a tar extract it patch then tar it again and have portage handle installation and receive an seccess or error? ebuilds with SRC_URI, can I pause the process edit the files and continue, I really do not know how any of that works, heck even if you tell me that the information I am looking for is in man portage or man ebuild I'd be dumbfounded
- GDH-gentoo
- Advocate
- Posts: 2114
- Joined: Sat Jul 20, 2019 7:02 pm
- Location: South America
This is hard to parsecoalms wrote:on another note this is not a rant but a request irrelevant of the original post, I understand sometimes it would be better to put my money where my mouth is and help out, regardless of my abysmal C skills I have no idea how ebuild development works, do I need the gentoo-dev use flag active on portage? do I prevent portage from fetching and wipeing my ebuild edits or make an overlay and test my builds there like the Basic guide on writeing Gentoo Ebuilds wiki says? No seriously no sarcasm or arrogance in my words at all, I haven't used gentoo for more then 12 months tops and most of that time my system was stable becuase I had a stable glibc/hardened system so thinks like bugs never crossed paths with me it is just that wikis are edited by so many people that sometimes they feel inconsistent to look for information and I wouldn't be able to even know where to start even when I'm thinking "I should be able to fix this myself", so yeah if you see this please DO give me a link or two on how gentoo package development and patching USUALLY works, I know how to make the patches from the orig.c and patches.c files themselves and how place them in etc portage patches but thats about it, dunno where to look for the source either, do I find a tar extract it patch then tar it again and have portage handle installation and receive an seccess or error? ebuilds with SRC_URI, can I pause the process edit the files and continue, I really do not know how any of that works, heck even if you tell me that the information I am looking for is in man portage or man ebuild I'd be dumbfounded
From what I think I could understand:This is enough for solving problems like the one in the subject... If you know what to patch.coalms wrote:[...] patching USUALLY works, I know how to make the patches from the orig.c and patches.c files themselves and how place them in etc portage patches but thats about it, [...]
In the case of package sys-libs/libselinux, it seems that at least the call to lstat64() in file libselinux/src/selinux_restorecon.c should be changed to a call to plain lstat(), and the type of local variable sb, to struct stat.
emerge --fetchonly package-name will download the source archive in your DISTDIR directory (usually /var/cache/distfiles).coalms wrote:[...] dunno where to look for the source either, [...]
Ionen wrote:As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though
so source is being kept in /var/cache/distfiles, brilliant, I was hoping for the simplicity of it being just extract edit and compress again but I honestly was not expecting it, I'll be honestly spending a lot more time in the future finding bug fixes in github rather then bugzilla now <3GDH-gentoo wrote:emerge --fetchonly package-name will download the source archive in your DISTDIR directory (usually /var/cache/distfiles).coalms wrote:[...] dunno where to look for the source either, [...]