sys-fs/e2fsprogs sys-libs/e2fsprogs-libs sys-libs/cracklib support for FreeMiNT.
Created attachment 179579 [details, diff] sys-libs/cracklib-2.8.13.ebuild patch
Created attachment 179580 [details, diff] sys-fs/e2fsprogs-1.41.3-r1.ebuild patch
Created attachment 179582 [details, diff] sys-libs/e2fsprogs-libs-1.41.3-r1.ebuild patch
Created attachment 179583 [details, diff] sys-fs/e2fsprogs-1.41.3-r1 files patch
(In reply to comment #1) > Created an attachment (id=179579) [edit] > sys-libs/cracklib-2.8.13.ebuild patch > Done (In reply to comment #2) > Created an attachment (id=179580) [edit] > sys-fs/e2fsprogs-1.41.3-r1.ebuild patch > The previous behavior was to enable-elf-shlibs globally, with you patch it is only done on mint. Intended? (In reply to comment #3) > Created an attachment (id=179582) [edit] > sys-libs/e2fsprogs-libs-1.41.3-r1.ebuild patch > It is bad to make arbitrary changes to ebuilds. gentoo-x86 does libtype=foo, so we do that too. The diff list gets huge otherwise.
(In reply to comment #5) > (In reply to comment #1) > > Created an attachment (id=179579) [edit] > > sys-libs/cracklib-2.8.13.ebuild patch > > > > Done Thanks. > (In reply to comment #2) > > Created an attachment (id=179580) [edit] > > sys-fs/e2fsprogs-1.41.3-r1.ebuild patch > > > > The previous behavior was to enable-elf-shlibs globally, with you patch it is > only done on mint. Intended? We only enable-elf-shlibs when != mint > > (In reply to comment #3) > > Created an attachment (id=179582) [edit] > > sys-libs/e2fsprogs-libs-1.41.3-r1.ebuild patch > > > > It is bad to make arbitrary changes to ebuilds. gentoo-x86 does libtype=foo, so > we do that too. The diff list gets huge otherwise. I can't see that libtype=none would work. Help??
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #1) > > > Created an attachment (id=179579) [edit] > > > sys-libs/cracklib-2.8.13.ebuild patch > > > > > > > Done > > Thanks. > > > (In reply to comment #2) > > > Created an attachment (id=179580) [edit] > > > sys-fs/e2fsprogs-1.41.3-r1.ebuild patch > > > > > > > The previous behavior was to enable-elf-shlibs globally, with you patch it is > > only done on mint. Intended? > > We only enable-elf-shlibs when != mint > > > > > (In reply to comment #3) > > > Created an attachment (id=179582) [edit] > > > sys-libs/e2fsprogs-libs-1.41.3-r1.ebuild patch > > > > > > > It is bad to make arbitrary changes to ebuilds. gentoo-x86 does libtype=foo, so > > we do that too. The diff list gets huge otherwise. > > I can't see that libtype=none would work. Help?? Also, the diff list wouldn't get huge as there's still a global catchall. It's just what we're encapsulating changes and I can't see a problem with it.
adding base-system to CC as described in bug 256535.
i'm guessing this is because FreeMiNT lacks support for shared libraries ? the changes you propose here are going to be required in a lot more places. i imagine FreeMiNT isnt the only port that will be static-only, so it'll probably be smarter to abstract this out a step and key off of that. as for the ldscript changes, i just committed a patch i had cooking locally for a while ... for example, the acl ebuild can now look like: gen_usr_ldscript -a acl and then all the magic of moving libacl.so* from /usr/lib/ to /lib/ is handled there. that means the static-only logic can be moved to that one place and then we convert ebuilds to use the new style (without needing to check for the mint CHOST in any ebuild).
That's cool about the -a flag. I'd posted a request to move this kind of thing to the prefix lists. Good work !
(In reply to comment #9) > i'm guessing this is because FreeMiNT lacks support for shared libraries ? > > the changes you propose here are going to be required in a lot more places. i > imagine FreeMiNT isnt the only port that will be static-only, so it'll probably > be smarter to abstract this out a step and key off of that. > > as for the ldscript changes, i just committed a patch i had cooking locally for > a while ... for example, the acl ebuild can now look like: > gen_usr_ldscript -a acl > > and then all the magic of moving libacl.so* from /usr/lib/ to /lib/ is handled > there. that means the static-only logic can be moved to that one place and > then we convert ebuilds to use the new style (without needing to check for the > mint CHOST in any ebuild). > Thanks, I'll let this cook here until grobian is awake. You have given us some horsepower to go ahead with merging moreso into gentoo-x86. Many influential people (you, Robin, & Zac at least) in Gentoo have expressed the same now.
Can these be added as is for now, until the mainline gets the gen_usr_ldscript changes we'll be able to fix up on top of that.
no changes can be made until questions asked actually get answered the patches in question arent going into the main tree ... i merge the real deal, not workarounds we're going to simply revert later
I lost track of what is the problem where and what is the proper fix.
Me too. I was talking about committing the patches to the prefix tree, until the gen_usr_ldscript changes land into us from mainilne. If there's something else, then I need more context to generate a new patch.
(In reply to comment #12) > Can these be added as is for now, until the mainline gets the gen_usr_ldscript > changes we'll be able to fix up on top of that. > (I sense a communication breakdown here - I already told all of this to you in irc - or thought I did) Both gentoo-x86 and hence Gentoo Prefix has this new gen_usr_ldscript -a flag. http://overlays.gentoo.org/proj/alt/changeset/37468 So, now we are waiting on new patches for the above packages such that they are fit for the gentoo-x86 tree as vapier requested. Me? I don't really understand much of this lib stuff tbh, so it is up for review from people that know.
I don't remember seeing this in IRC. Anyway, it seems to me that toolchain-funcs.eclass needs modifying for the other architectures to do the actual "mv" as it's already done for the catchall case. For FreeMiNT, it's already done as we don't do anything on this anyway. grobian is best placed to fix toolchain-funcs.eclass, and then it's a simple cleanup of the ebuild to call gen_usr_ldscript -a and remove the other cruft. grobian if there is anything I can do to help I will, but you could probably do this in a few minutes.
as i asked earlier, is FreeMiNT static only ? or does it support shared libraries ? in other words, i dont want to add any special casing based on target when we dont have to. the static-only aspect should be expressed in the profile and then the toolchain eclass can queue off of that. that way the next static-only port we get wont need to be updated all over the place.
FreeMiNT is static only. But in prefix portage the toolchain-funcs.eclass is already special cased for the gen_usr_ldscript function. For the build, we could base of the USE="static" and turn off elf-shlibs. So instead of .... [[ ${CHOST} != *-mint* ]] && myconf="--enable-elf-shlibs" we do... use static || myconf="--enable-elf-shlibs" Am I missing something else ??
To add, I guess in gen_usr_ldscript we can also check "use static" and bail early.
USE=static controls the generation of static executables only. it does not affect shared/static libraries in any way.
Then I need help, as I'm unsure what to do.
I'm willing to put the effort in, but I need some coaching here.
Regarding the shared/non-shared stuff. If I understand well, vapier, you have some ideas on how to do it nicely. Currently for ebuilds like readline we do ugly hacks like so: http://overlays.gentoo.org/proj/alt/changeset?new=trunk%2Fprefix-overlay%2Fsys-libs%2Freadline%2Freadline-5.2_p13.ebuild%4035837&old=trunk%2Fprefix-overlay%2Fsys-libs%2Freadline%2Freadline-5.2_p13.ebuild%4034776 I currently do not yet see what you have in mind, but I'm open for any improvement. All ebuilds that do gen_usr_ldscript stuff needed some patches for MiNT regarding the shared libraries like so.
a USE flag solution would require updating IUSE in every package and that's not nice. perhaps maintaining the list in get_libname() and having the return value of "a" indicate that the system is static-only would scale, and it seems to be the route you're going in prefix. i dont understand the aix case in that patch you referenced though. what does the aix setup look like ?
(In reply to comment #25) > i dont understand the aix case in that patch you referenced though. what does > the aix setup look like ? AIX has the wonderful approach to have "shared libraries" stored in .a archives. Hence one can't go blindly by the extension. (I agree that it is ugly code in the ebuilds though...)
What can I do to help this along ?
Unlike what we do currently, we could omit moving libs to EPREFIX/lib on AIX, and keep everything in EPREFIX/usr/lib. On native AIX, /lib is symlinked to /usr/lib anyway. So for gen_usr_ldscripts, it should work to skip everything for *.a. OTOH: I'm still not sure if I finally want *.a on AIX, see URL in bug#213277 for some variants I have tried...
Ping, anything I can help with ???
What is currently implemented for FreeMiNT is that nothing is done, which I thought was the desired thing to do?
ok, `gen_usr_ldscript -a` has been implemented in the meanwhile, alongside with a tc-is-static-only() function. gen_usr_ldscript -a avoids the conditional moving of files to /lib tc-is-static-only can be used to disable the elf shared libs instead of hardcoded mint
cracklib ebuild can simply be fixed by using `gen_usr_ldscript -a crack` instead of the manual move + gen_usr_ldscrip call. Done so in Prefix. --- cracklib-2.8.13.ebuild 9 May 2009 18:13:56 -0000 1.12 +++ cracklib-2.8.13.ebuild 14 Jun 2009 11:40:42 -0000 @@ -48,9 +48,7 @@ rm -r "${D}"/usr/share/cracklib # move shared libs to / - dodir /$(get_libdir) - mv "${D}"/usr/$(get_libdir)/*.so* "${D}"/$(get_libdir)/ || die "could not move shared" - gen_usr_ldscript libcrack.so + gen_usr_ldscript -a crack insinto /usr/share/dict doins dicts/cracklib-small || die "word dict" @base-system: ok to apply in gx86?
Will the other e2fs patches on this bug get taken care of like this ?
yesterday my time ran out, but I'm planning to, yes.
things like the cracklib can be committed (with a revbump) to the main tree
I believe I've finally done everything that needed to be done here.
sys-libs/e2fsprogs-libs patch seems to be missing most of it. Re-opening.
also local libtype should now be... local myconf
Also, the keywording for ~m68k-mint is missing.
well, keywords are missing, but the ebuilds should be ok. I didn't go with your patches because they were against I don't know what (they did not include existence of Darwin).
Eh ? I'm not sure what Darwin has to do with my patches, but it's listed in the description above which ebuilds they were made for. Please explain if I need to do something.
keywords committed, please open a new bug if something seems not to be working now.
this patch breaks other platforms actually, such as Darwin: snippet: CC version.c CC mint_io.c CC xhdi.c In file included from xhdi.c:35: xhdi.h:123: error: expected declaration specifiers or ‘...’ before ‘ulong’ xhdi.h:123: error: expected declaration specifiers or ‘...’ before ‘ulong’ xhdi.h:129: error: expected declaration specifiers or ‘...’ before ‘ulong’ xhdi.h:132: error: expected declaration specifiers or ‘...’ before ‘ulong’ xhdi.h:133: error: expected declaration specifiers or ‘...’ before ‘ulong’ xhdi.h:133: error: expected declaration specifiers or ‘...’ before ‘ulong’ xhdi.h:134: error: expected declaration specifiers or ‘...’ before ‘ulong’ xhdi.h:134: error: expected declaration specifiers or ‘...’ before ‘ulong’ xhdi.h:135: error: expected ‘)’ before ‘key1’ xhdi.h:136: error: expected declaration specifiers or ‘...’ before ‘ulong’ xhdi.h:136: error: expected declaration specifiers or ‘...’ before ‘ulong’ xhdi.h:139: error: expected declaration specifiers or ‘...’ before ‘ulong’ xhdi.h:140: error: expected declaration specifiers or ‘...’ before ‘ulong’ xhdi.c:40:23: error: mintbind.h: No such file or directory xhdi.c:41:26: error: mint/cookie.h: No such file or directory xhdi.c: In function ‘init_XHDI’: xhdi.c:76: error: ‘C_FOUND’ undeclared (first use in this function) xhdi.c:76: error: (Each undeclared identifier is reported only once xhdi.c:76: error: for each function it appears in.) xhdi.c:86: warning: assignment from incompatible pointer type xhdi.c: At top level: xhdi.c:153: error: expected declaration specifiers or ‘...’ before ‘ulong’ xhdi.c:153: error: expected declaration specifiers or ‘...’ before ‘ulong’ xhdi.c: In function ‘XHInqTarget’: xhdi.c:160: error: expected specifier-qualifier-list before ‘ulong’ xhdi.c:169: error: ‘block_size’ undeclared (first use in this function) xhdi.c:169: warning: excess elements in struct initializer I'm conditionalising the patch for now
nothing to do here for base-system any more
The xhdi.c file should have... #ifdef __MINT__ ... #endif around the entire file.
other than that, we should be fine here, don't we?