Re: [gentoo-dev] RFC: News item for default-linux removal (bug #287976)
On 10:52 Wed 21 Oct , Alec Warner wrote: > I'm trying to avoid using 'you' in the announcement which is why all > the rewording. I encourage informal language and speaking directly to the users. Use of "you" and "we" helps us to better connect with users through the documentation. It also has the nice benefit of avoiding stilted formalities and awkwardness like "one should do this..." or trying to use "people should" or "users should". -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com
[gentoo-dev] [Last rites]: sys-kernel/sh-sources
# Raúl Porcel (22 Oct 2009) # Not needed anymore, vanilla kernel works # pretty well on SH nowadays. # Removal in 30 days sys-kernel/sh-sources
Re: [gentoo-dev] Support for multiple ABIs for amd64 (64bit,32bit) in multilib overlay
Mike Frysinger schrieb:
> On Sunday 18 October 2009 14:46:07 Thomas Sachau wrote:
>> Mike Frysinger schrieb:
>>> another quick look at _setup_abi_env() looks like it needs work:
>>> - LD should not default to `ld`
>> Whats your suggestion?
>
> the majority of the time, the compiler driver (i.e. `gcc`) should be used for
> linking. very few packages should invoke the linker directly. that is why
> currently the toolchain-func.eclass has tc-getLD return `ld` -- a few
> packages
> need it, but not most. if we're going to be forcing the setting of the LD
> env
> var all the time, then it needs to default to ${CC}. packages that need
> funky
> behavior should still work as they will be calling $(tc-getLD) anyways.
Dropped $LD for now, seems to work fine for me.
>
>>> - the -L paths to system dirs in LDFLAGS should not be there -- the
>>> toolchain can handle these just fine
>> Last time i tried without, some packages failed to compile, will test it
>> again to check, if its still needed
>
> if things are failing, then we should look at gcc/binutils to make sure they
> use the right default search paths when given -m32/-m64
I currently dont export any explicit LDFLAGS, but instead only save the value
at the end of each
phase, seems to work fine for me.
>
>>> how do you control whether the multilib headers are needed ? it'll
>>> probably make sense in general, but there are def some packages where
>>> this will only get in the way (the toolchain ones).
>> What do you mean here? If the diff between ABIs makes sense to install
>> seperate versions?
>
> some packages (like glibc and linux-headers) already handle the multilib
> situation. forcing the unnecessary Gentoo layer into the stack can easily
> break things.
For glibc, it is avoided since it has the "multilib" useflag. If this is
enabled, it indicates for
me that the package does handle everything for itself, so multilib-portage does
handle it as if it
would be a normal package without multi-ABI request.
Since linux-headers do also some special multilib handling, could you also add
a "multilib" useflag
for them? Currently i have an exception for them in my code to prevent problems
for other packages.
I assume that ever package not having a multilib useflag does not any
multilib-specific action. To
check, if the header files differ per ABI, i save them for both ABIs, then diff
them and create
ABI-specific header files with a wrapper for all header files, that differ. The
rest is just
installed as usual.
>>> how do you differentiate between packages where multi ABIs make no sense
>>> ? for example, most packages that dont install any libraries but just
>>> binaries. let's use the simple package app-text/tree.
>> I dont differentiate. Currently i build for every ABI, if lib32 useflag is
>> set and multilib useflag is not set. The idea behind it is to allow the
>> installation of additional 32bit binaries, if requested.
>
> that's is an immense waste of time. if we ran all the source phases for a
> single ABI in one go, it should be easy to dynamically detect when a multilib
> multipass is necessary (by looking at library paths in $D). and for the odd
> package out, create a hook of some sort (EMULTIABI=true) to force behavior.
>
> i dont think there is any inherit reliance on running the multilib pass on
> each src step every time (other than that was easiest to implement) ?
For packages with header files, i need to run all phases for both ABIs to
check, if the header files
are ABI specific.
So it would require a check for installed libs and installed header files. And
its more work since
it requires both changes to the ebuild and emerge command.
>
>>> a lot of this multilib code should probably continue to live in the tree
>>> as it's a pretty big base of code to formalize that could do with fixes
>>> over time. i.e. we figure out that certain paths / define protections
>>> dont work so well, so changing them to something else would require PMS
>>> changing !? there has been talk before about pushing a lot of basic
>>> stuff to the tree so things dont have to be encoded in the PMS.
>> How do you want to do this? Require package managers to inherit some
>> file/eclass?
>
> considering this requires changes to the PM already, i dont see why not. and
> it wouldnt really be an inherit in the current sense of the word. more like
> a
> simple source.
I am ok with this suggestion.
>
>>> how are packages handled that can only be used via 1 ABI ? any of the
>>> packages listed in the amd64 no-multilib package.mask for example. while
>>> these are mostly binary-only, this isnt a binary-specific issue. there
>>> are a number of packages which only work on x86/ppc but could easily work
>>> in a multilib amd64/ppc64 as a 32bit binary (source code sucks, is
>>> heavily asm, something else).
>> The binary-only ones are easy. Since they dont interact with the env, they
>> can be installed as usual. If they
Re: [gentoo-dev] Support for multiple ABIs for amd64 (64bit,32bit) in multilib overlay
Mike Frysinger schrieb:
> On Monday 19 October 2009 16:59:55 Thomas Sachau wrote:
>> Mike Frysinger schrieb:
>>> the majority of the time, the compiler driver (i.e. `gcc`) should be used
>>> for linking. very few packages should invoke the linker directly. that
>>> is why currently the toolchain-func.eclass has tc-getLD return `ld` -- a
>>> few packages need it, but not most. if we're going to be forcing the
>>> setting of the LD env var all the time, then it needs to default to
>>> ${CC}. packages that need funky behavior should still work as they will
>>> be calling $(tc-getLD) anyways.
>>>
> - the -L paths to system dirs in LDFLAGS should not be there -- the
> toolchain can handle these just fine
Last time i tried without, some packages failed to compile, will test it
again to check, if its still needed
>>> if things are failing, then we should look at gcc/binutils to make sure
>>> they use the right default search paths when given -m32/-m64
>> This is an example from configure failure with ABI=x86 for cvs-1.12.12-r6
>>
>> last lines from configure:
>>
>> checking for ssh... ssh
>> checking for vim... /bin/nano
>> checking for temporary directory... /tmp
>> checking security/pam_appl.h usability... yes
>> checking security/pam_appl.h presence... yes
>> checking for security/pam_appl.h... yes
>> checking for pam_start in -lpam... no
>> configure: error: Could not find PAM libraries but the headers exist.
>> Give the --disable-pam option to compile without PAM support (or fix
>> your broken configuration)
>>
>> !!! Please attach the following file when seeking support:
>> !!! /var/tmp/portage/dev-util/cvs-1.12.12-r6/work/cvs-1.12.12/config.log
>> * ERROR: dev-util/cvs-1.12.12-r6 failed:
>> * econf failed
>>
>> relevant lines from config.log:
>>
>> configure:38697: checking for pam_start in -lpam
>> configure:38727: x86_64-pc-linux-gnu-gcc -o conftest -march=nocona -O2
>> -pipe -m32 -L/emul/linux/x86/lib -L/emul/linux/x86/usr/lib -march=nocona
>> -O2 -pipe -Wl,--as-needed conftest.c -lpam -lnsl -lz >&5
>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/../../../../lib32/libpam.a(pam_dynam
>> ic.o): In function `_pam_dlerror':
>> (.text+0x1f): undefined reference to `dlerror'
>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/../../../../lib32/libpam.a(pam_dynam
>> ic.o): In function `_pam_dlclose':
>> (.text+0x5f): undefined reference to `dlclose'
>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/../../../../lib32/libpam.a(pam_dynam
>> ic.o): In function `_pam_dlsym':
>> (.text+0xa6): undefined reference to `dlsym'
>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/../../../../lib32/libpam.a(pam_dynam
>> ic.o): In function `_pam_dlopen':
>> (.text+0xf2): undefined reference to `dlopen'
>> collect2: ld returned 1 exit status
>> configure:38733: $? = 1
>>
>> If you need some more lines or complete build.log/config.log, feel free to
>> tell me and i will send them directly.
>
> please open a bug about this for the toolchain guys. i dont know when i'll
> get to researching this.
> -mike
Seems like it was some temporary issue, cannot reproduce it now, so ignore it
for now.
--
Thomas Sachau
Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] License group proposal: @BINARY-REDISTRIBUTABLE
My vote for it, sounds reasonable. Sebastian
Re: [gentoo-dev] Re: RFC: News item for default-linux removal (bug #287976)
Duncan wrote: > Samuli Suominen posted on Wed, 21 Oct 2009 21:00:43 +0300 as excerpted: > >> If a machine is not migrated to a new valid profile then emerge will >> have very limited functionality. > > If a machine is not migrated to a new valid profile before the deprecated > profiles are removed, emerge will have very limited functionality until > the migration is done. > > Alternatively: > > If a machine is not migrated to a new valid profile before 2009-12-01, > ... > Fine by me. Thanks. I've tested this one working, had to add multiple Display-If-Profiles because the GLEP and Portage doesn't support having just "default-linux". Draft: Title: Using default-linux profile is now obsolete Author: Samuli Suominen Content-Type: text/plain Posted: 2009-10-21 Revision: 1 News-Item-Format: 1.0 Display-If-Profile: default-linux/alpha Display-If-Profile: default-linux/amd64 Display-If-Profile: default-linux/arm Display-If-Profile: default-linux/ia64 Display-If-Profile: default-linux/m68k Display-If-Profile: default-linux/s390 Display-If-Profile: default-linux/sh Display-If-Profile: default-linux/sparc Display-If-Profile: default-linux/x86 The profiles in default-linux/ have been deprecated for six weeks. Users using these profiles are expected to migrate to a new profile before 2009-12-01, at which point the default-linux/ profiles will be removed. The new profiles contain up to date configurations and were adopted because they were easier to maintain. Users can switch to a new profile using eselect: # eselect profile list # eselect profile set If a machine is not migrated to a new valid profile before the deprecated profiles are removed, emerge will have very limited functionality until the migration is done.
