FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 03-07-2011, 09:24 AM
Mike Frysinger
 
Default multilib clean up

i plan on punting these (hardly used) functions from the
multilib.eclass (once the handful of open bugs are closed):
get_ml_incdir
prep_ml_includes
create_ml_includes
create_ml_includes-absolute
create_ml_includes-tidy_path
create_ml_includes-listdirs
create_ml_includes-makedestdirs
create_ml_includes-allfiles
create_ml_includes-sym_for_dir
further, the CDEFINE_xxx multilib vars will go with them

for the most part, these were really only used by the glibc ebuilds.
for the ones that dont support multilib natively (and necessitated
these funcs in the first place), i'll simply punt the ebuilds. this
will probably be just the glibc-2.5 ebuilds for now.

also, i'll be converting the glibc ebuilds do always invoke the
multilib_env helper functions. this will allow us to drop the
{C,LD}FLAGS_xxx and friends from profiles since glibc was the main
consumer. i imagine this inadvertently break some other packages, so
if people want to test this on their own systems before i make the
commit, that'd be cool. the plan would be for said breakage will go
through bugzilla to get the ebuild updated rather than reverting the
profile.
-mike
 
Old 03-07-2011, 04:35 PM
Thomas Sachau
 
Default multilib clean up

Am 07.03.2011 11:24, schrieb Mike Frysinger:
> i plan on punting these (hardly used) functions from the
> multilib.eclass (once the handful of open bugs are closed):
> get_ml_incdir
> prep_ml_includes
> create_ml_includes
> create_ml_includes-absolute
> create_ml_includes-tidy_path
> create_ml_includes-listdirs
> create_ml_includes-makedestdirs
> create_ml_includes-allfiles
> create_ml_includes-sym_for_dir
> further, the CDEFINE_xxx multilib vars will go with them
>
> for the most part, these were really only used by the glibc ebuilds.
> for the ones that dont support multilib natively (and necessitated
> these funcs in the first place), i'll simply punt the ebuilds. this
> will probably be just the glibc-2.5 ebuilds for now.
>
> also, i'll be converting the glibc ebuilds do always invoke the
> multilib_env helper functions. this will allow us to drop the
> {C,LD}FLAGS_xxx and friends from profiles since glibc was the main
> consumer. i imagine this inadvertently break some other packages, so
> if people want to test this on their own systems before i make the
> commit, that'd be cool. the plan would be for said breakage will go
> through bugzilla to get the ebuild updated rather than reverting the
> profile.
> -mike
>
>

Please leave those vars in the profile, i depend on them in multilib-portage to crosscompile e.g.
for x86 on the amd64 profile. If you remove them now, they would be re-added again once
multilib-portage (and the related EAPI) become official, so imho we can just leave them in for now.

--
Thomas Sachau

Gentoo Linux Developer
 
Old 03-07-2011, 09:29 PM
Mike Frysinger
 
Default multilib clean up

On Monday, March 07, 2011 12:35:53 Thomas Sachau wrote:
> Am 07.03.2011 11:24, schrieb Mike Frysinger:
> > also, i'll be converting the glibc ebuilds do always invoke the
> > multilib_env helper functions. this will allow us to drop the
> > {C,LD}FLAGS_xxx and friends from profiles since glibc was the main
> > consumer. i imagine this inadvertently break some other packages, so
> > if people want to test this on their own systems before i make the
> > commit, that'd be cool. the plan would be for said breakage will go
> > through bugzilla to get the ebuild updated rather than reverting the
> > profile.
>
> Please leave those vars in the profile, i depend on them in
> multilib-portage to crosscompile e.g. for x86 on the amd64 profile. If you
> remove them now, they would be re-added again once multilib-portage (and
> the related EAPI) become official, so imho we can just leave them in for
> now.

these need to be centralized somehow. duplicating multilib.eclass and the
profiles indefinitely isnt going to fly.

perhaps we unify all the multilib settings into one file such as
base/make.defaults ... that would require normalizing of the ABI value across
all targets, but i dont think that's an issue.
-mike
 
Old 03-16-2011, 07:08 PM
Mike Frysinger
 
Default multilib clean up

the next tweak i'll be making is the order of paths returned by
get_all_libdirs. it guarantees "lib" to always be in the list and it does
this simply by having it be the first item. i cant see this position being a
hard requirement, just a coding convenience, and it's desirable to have the
paths follow the actual ABI dir preferences (e.g. Bug 357225).

so the new code will return paths according to the MULTILIB_ABIS order, and
then append "lib" only if it hasnt already been posted. assumption here is
that "lib" is only showing up if people want to symlink or otherwise fake it,
and so prefer the native paths first.

in looking at the few packages that actually use this function, i cant see any
problems. it's used to set up search paths and preferring the "faked" dir
over the real dir, or even a diff ABI over the active ABI, shouldn't be an
issue.
-mike
 
Old 03-18-2011, 06:46 PM
Mike Frysinger
 
Default multilib clean up

gcc-config-1.5 will no longer implicitly append CFLAGS_<abi> to the compile.
this should be unnecessary now that multilib.eclass and glibc add the required
multilib flags explicitly to CC/CFLAGS/etc...
-mike
 
Old 03-18-2011, 09:08 PM
Mike Frysinger
 
Default multilib clean up

On Monday, March 07, 2011 05:24:29 Mike Frysinger wrote:
> i plan on punting these (hardly used) functions from the
> multilib.eclass (once the handful of open bugs are closed):
> get_ml_incdir
> prep_ml_includes
> create_ml_includes
> create_ml_includes-absolute
> create_ml_includes-tidy_path
> create_ml_includes-listdirs
> create_ml_includes-makedestdirs
> create_ml_includes-allfiles
> create_ml_includes-sym_for_dir
> further, the CDEFINE_xxx multilib vars will go with them

ive done this now
-mike
 

Thread Tools




All times are GMT. The time now is 01:42 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org