Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 256234 - patch for e2fsprogs FreeMiNT support
Summary: patch for e2fsprogs FreeMiNT support
Status: RESOLVED FIXED
Alias: None
Product: Gentoo/Alt
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All FreeMiNT
: High normal (vote)
Assignee: Gentoo Prefix
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-24 20:55 UTC by Alan Hourihane
Modified: 2009-10-03 14:30 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
sys-libs/cracklib-2.8.13.ebuild patch (cracklib.patch,508 bytes, patch)
2009-01-24 20:56 UTC, Alan Hourihane
Details | Diff
sys-fs/e2fsprogs-1.41.3-r1.ebuild patch (e2fsprogs.patch,1.11 KB, patch)
2009-01-24 20:56 UTC, Alan Hourihane
Details | Diff
sys-libs/e2fsprogs-libs-1.41.3-r1.ebuild patch (e2fsprogs-libs.patch,1.30 KB, patch)
2009-01-24 20:57 UTC, Alan Hourihane
Details | Diff
sys-fs/e2fsprogs-1.41.3-r1 files patch (e2fsprogs-1.41-mint.patch,38.30 KB, patch)
2009-01-24 20:57 UTC, Alan Hourihane
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Hourihane 2009-01-24 20:55:58 UTC
sys-fs/e2fsprogs
sys-libs/e2fsprogs-libs
sys-libs/cracklib

support for FreeMiNT.
Comment 1 Alan Hourihane 2009-01-24 20:56:28 UTC
Created attachment 179579 [details, diff]
sys-libs/cracklib-2.8.13.ebuild patch
Comment 2 Alan Hourihane 2009-01-24 20:56:54 UTC
Created attachment 179580 [details, diff]
sys-fs/e2fsprogs-1.41.3-r1.ebuild patch
Comment 3 Alan Hourihane 2009-01-24 20:57:18 UTC
Created attachment 179582 [details, diff]
sys-libs/e2fsprogs-libs-1.41.3-r1.ebuild patch
Comment 4 Alan Hourihane 2009-01-24 20:57:40 UTC
Created attachment 179583 [details, diff]
sys-fs/e2fsprogs-1.41.3-r1 files patch
Comment 5 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2009-01-27 15:58:21 UTC
(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.
Comment 6 Alan Hourihane 2009-01-27 16:06:25 UTC
(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??

Comment 7 Alan Hourihane 2009-01-27 17:04:56 UTC
(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.
Comment 8 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2009-01-27 23:18:49 UTC
adding base-system to CC as described in bug 256535.
Comment 9 SpanKY gentoo-dev 2009-01-27 23:36:43 UTC
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).
Comment 10 Alan Hourihane 2009-01-27 23:39:33 UTC
That's cool about the -a flag. I'd posted a request to move this kind of thing to the prefix lists. Good work !
Comment 11 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2009-01-28 00:32:21 UTC
(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.
Comment 12 Alan Hourihane 2009-02-05 00:46:43 UTC
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.
Comment 13 SpanKY gentoo-dev 2009-02-05 06:58:20 UTC
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
Comment 14 Fabian Groffen gentoo-dev 2009-02-05 08:38:52 UTC
I lost track of what is the problem where and what is the proper fix.
Comment 15 Alan Hourihane 2009-02-05 09:44:12 UTC
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.
Comment 16 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2009-02-05 15:29:16 UTC
(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.
Comment 17 Alan Hourihane 2009-02-05 15:45:37 UTC
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.
Comment 18 SpanKY gentoo-dev 2009-02-05 16:00:14 UTC
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.
Comment 19 Alan Hourihane 2009-02-05 16:55:32 UTC
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 ??
Comment 20 Alan Hourihane 2009-02-05 17:15:26 UTC
To add, I guess in gen_usr_ldscript we can also check "use static" and bail early.
Comment 21 SpanKY gentoo-dev 2009-02-05 19:38:51 UTC
USE=static controls the generation of static executables only.  it does not affect shared/static libraries in any way.
Comment 22 Alan Hourihane 2009-02-05 20:51:16 UTC
Then I need help, as I'm unsure what to do.
Comment 23 Alan Hourihane 2009-02-06 00:59:57 UTC
I'm willing to put the effort in, but I need some coaching here.
Comment 24 Fabian Groffen gentoo-dev 2009-02-09 19:55:04 UTC
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.
Comment 25 SpanKY gentoo-dev 2009-02-11 06:04:50 UTC
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 ?
Comment 26 Fabian Groffen gentoo-dev 2009-02-11 08:30:02 UTC
(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...)
Comment 27 Alan Hourihane 2009-03-31 20:56:48 UTC
What can I do to help this along ?
Comment 28 Michael Haubenwallner (RETIRED) gentoo-dev 2009-04-01 09:01:07 UTC
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...
Comment 29 Alan Hourihane 2009-05-07 11:12:33 UTC
Ping, anything I can help with ???
Comment 30 Fabian Groffen gentoo-dev 2009-05-07 11:20:21 UTC
What is currently implemented for FreeMiNT is that nothing is done, which I thought was the desired thing to do?
Comment 31 Fabian Groffen gentoo-dev 2009-06-14 09:09:25 UTC
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
Comment 32 Fabian Groffen gentoo-dev 2009-06-14 21:42:50 UTC
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?
Comment 33 Alan Hourihane 2009-06-14 21:52:40 UTC
Will the other e2fs patches on this bug get taken care of like this ?
Comment 34 Fabian Groffen gentoo-dev 2009-06-15 08:47:44 UTC
yesterday my time ran out, but I'm planning to, yes.
Comment 35 SpanKY gentoo-dev 2009-06-20 13:25:06 UTC
things like the cracklib can be committed (with a revbump) to the main tree
Comment 36 Fabian Groffen gentoo-dev 2009-06-30 20:13:59 UTC
I believe I've finally done everything that needed to be done here.
Comment 37 Alan Hourihane 2009-06-30 20:20:35 UTC
sys-libs/e2fsprogs-libs patch seems to be missing most of it. Re-opening.
Comment 38 Alan Hourihane 2009-06-30 20:22:09 UTC
also 

local libtype

should now be...

local myconf
Comment 39 Alan Hourihane 2009-06-30 21:19:49 UTC
Also, the keywording for ~m68k-mint is missing.
Comment 40 Fabian Groffen gentoo-dev 2009-07-01 07:11:30 UTC
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).
Comment 41 Alan Hourihane 2009-07-01 08:13:09 UTC
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.
Comment 42 Fabian Groffen gentoo-dev 2009-07-01 18:41:41 UTC
keywords committed, please open a new bug if something seems not to be working now.
Comment 43 Fabian Groffen gentoo-dev 2009-07-06 20:04:08 UTC
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
Comment 44 Fabian Groffen gentoo-dev 2009-07-06 20:06:29 UTC
nothing to do here for base-system any more
Comment 45 Alan Hourihane 2009-07-06 20:13:10 UTC
The xhdi.c file should have...

#ifdef __MINT__

...

#endif 

around the entire file.
Comment 46 Fabian Groffen gentoo-dev 2009-10-03 14:30:05 UTC
other than that, we should be fine here, don't we?