Re: [gentoo-dev] Re: RFC: multilib and the compatibility to singlelib
On Tuesday 20 October 2009 16:47:50 Jonathan Callen wrote: > Mike Frysinger wrote: > >> The problem was that Gentoo's early amd64 implementation predated this > >> standardization, and we had chosen the other way. While we've defaulted > >> to lib64 for 64-bit libs for years, it has never been considered > >> anything but experimental to break the lib --> lib64 link. AFAIK stable > >> baselayout still doesn't get its libdir usage consistent, putting files > >> in one but actually calling them using the other path, and boot breaks > >> in various frustrating ways if lib and lib64 are not the same directory. > >> Openrc gets it better now, but I'm not sure it's all fixed either -- it > >> certainly wasn't last time I tried breaking the link. > > > > your "AFAIK" isnt useful. there are no open bugs about either version > > and people assume that it's doing the right thing. > > Personally, I do have a ~amd64 Gentoo chroot with LIBDIR_x86="lib". > There is only one place that I've found that it is still broken, namely > one line in toolchain.eclass (patch attached). I've been meaning to file > a bug for quite a while now, but never got around to it. off the top of my head, that doesnt really look like a correct fix. please open a bug with info on what you're actually doing. plus, your LIBDIR_x86 isnt really respected. there are places where lib32/lib64 are hardcoded when modifying gcc/binutils (patch or sed). -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Status of 10.0 profiles??
Hello, Since the "10.0 release" there has not been an outward facing announcement for users to switch profiles. * Are we deprecating the 2008.0 profiles? * Are 10.0 profiles "feature complete" ? * Will there be an announcement? * Why are only the 2008.0 hardened profiles deprecated? ( %% find /usr/portage/profiles -name deprecated ) If users are suppose to switch to 10.0, then is anyone from the t...@gentoo.org team planning on making the announcements? I would expect an email to gentoo-user, gentoo-announce, gentoo-dev-announce, #gentoo topic, and finally forums but that is just off the top of my head. About 10.0: I know it happened, I know there is an irc channel. But, that is about it. I think it would be nice if someone from the ten team could do a postmortem of what worked and what didn't. -Jeremy
[gentoo-dev] Re: RFC: multilib and the compatibility to singlelib
Mike Frysinger wrote:
> if you read FHS you'll see that both implementations are allowed. Gentoo
> isnt
> violating anything here. wrt LSB, who knows. there are a ton of things we
> dont follow with LSB.
Actually, at first, FHS says that any /lib would be allowed, but
it then goes into specifics in Chapter 6, Operating System Specific
Annex. Under the heading "/lib64 and /lib32 : 64/32-bit libraries
(architecture dependent)", it says, "The 64-bit architectures PPC64,
s390x, sparc64 and AMD64 must place 64-bit libraries in /lib64, and
32-bit (or 31-bit on s390) libraries in /lib."
>> The problem was that Gentoo's early amd64 implementation predated this
>> standardization, and we had chosen the other way. While we've defaulted
>> to lib64 for 64-bit libs for years, it has never been considered anything
>> but experimental to break the lib --> lib64 link. AFAIK stable
>> baselayout still doesn't get its libdir usage consistent, putting files
>> in one but actually calling them using the other path, and boot breaks in
>> various frustrating ways if lib and lib64 are not the same directory.
>> Openrc gets it better now, but I'm not sure it's all fixed either -- it
>> certainly wasn't last time I tried breaking the link.
>
> your "AFAIK" isnt useful. there are no open bugs about either version and
> people assume that it's doing the right thing.
Personally, I do have a ~amd64 Gentoo chroot with LIBDIR_x86="lib".
There is only one place that I've found that it is still broken, namely
one line in toolchain.eclass (patch attached). I've been meaning to file
a bug for quite a while now, but never got around to it.
--
Jonathan
--- /usr/portage/eclass/toolchain.eclass
+++ toolchain.eclass
@@ -1956,8 +1956,7 @@ gcc_movelibs() {
${LIBPATH}/${OS_MULTIDIR} \
${LIBPATH}/../${MULTIDIR} \
${PREFIX}/lib/${OS_MULTIDIR} \
- ${PREFIX}/${CTARGET}/lib/${OS_MULTIDIR} \
- ${PREFIX}/lib/${MULTIDIR}
+ ${PREFIX}/${CTARGET}/lib/${OS_MULTIDIR}
do
removedirs="${removedirs} ${FROMDIR}"
FROMDIR=${D}${FROMDIR}
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] KDE Team Meeting - October 2009
Greetings, The KDE Team will have its usual monthly meeting this Thursday. Date: Thursday, 2009/10/22 Time: 1900 UTC Channel: #gentoo-meetings Late announcement, I know, but I guess better late than never :) Reply to this email with anything you'd like to have discussed at the meeting. Everyone should be there so we can celebrate having KDE 4 stable! Thanks, -- Alex || wired Gentoo Dev www.linuxized.com
Re: [gentoo-dev] RFC: multilib and the compatibility to singlelib
On Tuesday 20 October 2009 09:06:29 Michael Haubenwallner wrote:
> As I'm building the toolchain myself too, I configure it with the
> 32bit host triplet on each platform, usually disabling multilib.
this doesnt make any sense to me
> This simply works for ppc-aix, hppa-hpux, ia64-hpux, sparc-solaris,
> x86-solaris, even if the underlying OS/kernel is 64bit.
> It isn't even necessary to explicitly use --{build,host} at all,
> as config.guess tells the 32bit triplet on these platforms.
> Additionally, even their default compiler output is 32bit.
>
> But Linux "is not Unix":
you're right, so i'm not terribly concerned with compatibility with non-Linux
systems. comparing the native Gentoo/Linux multilib setup to another Linux
multilib setup is the only useful comparison.
> Configuring both binutils and gcc needs to be done with:
> $ CC="gcc -m32" /path/to/configure --{build,host}=i686-pc-linux-gnu ...
> This works on 64bit RHEL as well as on 64bit SLES (both have 32bit in /lib,
> 64bit in /lib64, no /lib32), but breaks on amd64+multilib Gentoo Linux.
>
> Problem is that, as x86-linux isn't a multilib target, both ld and gcc
> search for 32bit libs&objects in /usr/lib:/lib, as they don't know about
> /usr/lib32:/lib32. The error when bootstrapping gcc is:
> /usr/lib/crti.o: file not recognized: File format not recognized
i dont get it. why does the i686-pc-linux-gnu toolchain target matter on an
amd64 multilib system ? the native x86_64-pc-linux-gnu toolchain should
already do the right thing when given -m32.
> While it is possible to patch binutils[1] and gcc[2] to search in
> /usr/lib32:/lib32 even with this otherways non-multilib target,
> it doesn't feel like the "right thing" to enable multilib for
> just one multilib option.
>
> Isn't the intention of multilib to have a new (64bit) system
> be compatible with the corresponding old (32bit) system?
your description of "compatible" is pretty vague. ignoring /lib -> /lib64
symlink (which shouldnt matter to any binaries), i'm not aware of any
differences off the top of my head.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Support for multiple ABIs for amd64 (64bit,32bit) in multilib overlay
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
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: multilib and the compatibility to singlelib
On Tuesday 20 October 2009 12:25:15 Duncan wrote: > Thomas Sachau posted on Tue, 20 Oct 2009 17:29:25 +0200 as excerpted: > > Michael Haubenwallner schrieb: > >> Isn't the intention of multilib to have a new (64bit) system be > >> compatible with the corresponding old (32bit) system? > >> > >> Please comment, thank you! > >> /haubi/ > > > > If you have a 64bit system, the default should be 64bit, both for libs > > and for binaries. The additional multilib support allows to install and > > use additional 32bit libs and binaries. Since they are not the system > > dafault, they shouldnt be in some default place like lib, but instead a > > different, but clearly labeled dir like lib32. So the Gentoo way looks > > like the right way to me. > > Except... it isn't, at least not if Gentoo is at all concerned about > standards, especially when they'll make things far easier for it. > > What you just described was the logic applied with, for example, ia64, > which is true 64-bit (only) native. However (as I understand it), the > Linux FHS and LSB used somewhat different logic for x86_64. if you read FHS you'll see that both implementations are allowed. Gentoo isnt violating anything here. wrt LSB, who knows. there are a ton of things we dont follow with LSB. > See, x86_64 is hardware native dual-bitness, so both 32-bit and 64-bit > can be said to be true native hardware bitness (this is NOT the case with > ia64). you can word "true native hardware bitness" (i dont even know what that means) however you like. fact is, first ia64 gen had hardware support for x86. no software levels needed. we decided to not support ia64 multilib because (1) the hardware sucked so bad and (2) no one actually wanted it and (3) none of the mainline packages were/are doing it and (4) newer ia64 gens dropped support for it. > Apparently due to that and to the vast number of legacy 32-bit > apps around, many binary-only apps doing obscure and unpredictable things > that could well break if assumptions about lib proved invalid, they > decided to keep the 32-bit lib location just as it was, believing it > easier to create the new lib64 for 64-bit, then to worry about whatever > obscure and exotic stuff various binary-only apps might be doing. Since > this was just one more change to add to the list of changes already being > made to port apps to amd64, it was considered easier than the other way, > and thus became the standard. the only binary encoded 32bit /lib/ path is the ldso which is why we symlinked that too > The problem was that Gentoo's early amd64 implementation predated this > standardization, and we had chosen the other way. While we've defaulted > to lib64 for 64-bit libs for years, it has never been considered anything > but experimental to break the lib --> lib64 link. AFAIK stable > baselayout still doesn't get its libdir usage consistent, putting files > in one but actually calling them using the other path, and boot breaks in > various frustrating ways if lib and lib64 are not the same directory. > Openrc gets it better now, but I'm not sure it's all fixed either -- it > certainly wasn't last time I tried breaking the link. your "AFAIK" isnt useful. there are no open bugs about either version and people assume that it's doing the right thing. > So before Gentoo can switch to the FHS/LSB 32-bit lib on amd64 multilib, > it must first fix those last inconsistent usages, and make it possible to > break the lib --> lib64 link. Then in theory at least, after awhile with > no bugs, or at least no big ones related to this issue, it might be > considered safe to move 32-bit back to lib, where the LSB/FHS says it > should be. we've already switched to the FHS implementation -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: RFC: multilib and the compatibility to singlelib
Thomas Sachau posted on Tue, 20 Oct 2009 17:29:25 +0200 as excerpted: > Michael Haubenwallner schrieb: >> Isn't the intention of multilib to have a new (64bit) system be >> compatible with the corresponding old (32bit) system? >> >> Please comment, thank you! >> /haubi/ > > If you have a 64bit system, the default should be 64bit, both for libs > and for binaries. The additional multilib support allows to install and > use additional 32bit libs and binaries. Since they are not the system > dafault, they shouldnt be in some default place like lib, but instead a > different, but clearly labeled dir like lib32. So the Gentoo way looks > like the right way to me. Except... it isn't, at least not if Gentoo is at all concerned about standards, especially when they'll make things far easier for it. What you just described was the logic applied with, for example, ia64, which is true 64-bit (only) native. However (as I understand it), the Linux FHS and LSB used somewhat different logic for x86_64. See, x86_64 is hardware native dual-bitness, so both 32-bit and 64-bit can be said to be true native hardware bitness (this is NOT the case with ia64). Apparently due to that and to the vast number of legacy 32-bit apps around, many binary-only apps doing obscure and unpredictable things that could well break if assumptions about lib proved invalid, they decided to keep the 32-bit lib location just as it was, believing it easier to create the new lib64 for 64-bit, then to worry about whatever obscure and exotic stuff various binary-only apps might be doing. Since this was just one more change to add to the list of changes already being made to port apps to amd64, it was considered easier than the other way, and thus became the standard. The problem was that Gentoo's early amd64 implementation predated this standardization, and we had chosen the other way. While we've defaulted to lib64 for 64-bit libs for years, it has never been considered anything but experimental to break the lib --> lib64 link. AFAIK stable baselayout still doesn't get its libdir usage consistent, putting files in one but actually calling them using the other path, and boot breaks in various frustrating ways if lib and lib64 are not the same directory. Openrc gets it better now, but I'm not sure it's all fixed either -- it certainly wasn't last time I tried breaking the link. So before Gentoo can switch to the FHS/LSB 32-bit lib on amd64 multilib, it must first fix those last inconsistent usages, and make it possible to break the lib --> lib64 link. Then in theory at least, after awhile with no bugs, or at least no big ones related to this issue, it might be considered safe to move 32-bit back to lib, where the LSB/FHS says it should be. > And better support for this part is my current multilib-portage project, > which allows compilation and installation of additional 32bit libs and > binaries. While I'm a no-multilib user here, I'm glad someone's finally getting that close enough to mainline merge to talk about it! There's a lot of folks for whom it will make life far easier. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] RFC: multilib and the compatibility to singlelib
Michael Haubenwallner schrieb: > Isn't the intention of multilib to have a new (64bit) system > be compatible with the corresponding old (32bit) system? > > Please comment, thank you! > /haubi/ If you have a 64bit system, the default should be 64bit, both for libs and for binaries. The additional multilib support allows to install and use additional 32bit libs and binaries. Since they are not the system dafault, they shouldnt be in some default place like lib, but instead a different, but clearly labeled dir like lib32. So the Gentoo way looks like the right way to me. And better support for this part is my current multilib-portage project, which allows compilation and installation of additional 32bit libs and binaries. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: RFC: multilib and the compatibility to singlelib
On 10/20/2009 04:06 PM, Michael Haubenwallner wrote: Isn't the intention of multilib to have a new (64bit) system be compatible with the corresponding old (32bit) system? I'm not sure I understand the whole procedure you use to build this app. Why not simply use -m32 when building it? Why build a whole toolchain? Anyway, as for the question of multilib's intention, yes, it's to have a 64-bit and 32-bit userland at the same time. But it doesn't work fully on Gentoo, which is why the effort for real multilib support has started in the first place.
[gentoo-dev] virtualx.eclass changes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Recently, virtualx.eclass changed how it adds dependencies. Previously,
it always added IUSE=X, and added "X? ( x11-base/xorg-server
x11-apps/xhost )" to both DEPEND and RDEPEND (the RDEPEND part appears
to have been unintentional). This has been changed to instead be in the
control of the ebuild inheriting virtualx.
If you always need an X server to build, set VIRTUALX_REQUIRED=always
before inheriting virtualx, and the dependencies will be added to DEPEND
unconditionally.
If you only need an X server to run tests, just inherit virtualx. The
dependencies will be added with "test? ( )" around them, and "test" will
be added to IUSE.
If you need the X server under other conditions, set
VIRTUALX_REQUIRED=manual before inheriting virtualx, then use
${VIRTUALX_DEPEND} in DEPEND as needed.
This change has effectively removed the "X" USE flag from the following
packages where it should have been "test":
app-accessibility/gnome-mag
app-accessibility/gok
dev-libs/libunique
dev-python/gnome-python-desktop
dev-python/gnome-python-extras
dev-python/pygobject
dev-python/pygtk
gnome-base/eel
gnome-base/gnome-keyring
gnome-base/libbonoboui
gnome-base/libgnomecanvas
gnome-base/nautilus
gnome-extra/at-spi
gnome-extra/gnome-games
gnome-extra/gnome-power-manager
media-sound/rhythmbox
net-libs/webkit-gtk
sci-astronomy/wcslib
sci-mathematics/freemat
x11-libs/gtk+:2
x11-libs/guile-gtk
xfce-base/thunar
The following other packages also had changes for this:
app-crypt/heimdal:
the X server dep is now controlled by "test? ( X? ( ... ) )"
media-sound/rubyripper
the X server dep is now unconditional, and the package's X flag is
no longer in package.use.force.
- --
Jonathan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkrduS8ACgkQOypDUo0oQOrdGACeOajNxjLLoqw8A6aRC7G4vcTt
++wAn0qjITRs+V5tN0YZXjKkfLYs/lco
=edMH
-END PGP SIGNATURE-
[gentoo-dev] RFC: multilib and the compatibility to singlelib
Hi devs,
while there is the appreciated multiple ABI portage support going on,
a thought on the intentions of the multilib profiles.
Some background:
I do have to support building an older, but still maintained large
application software, that simply does not work when built as 64bit.
As it does not have the need itself for >32bit pointers, and all
the 64bit target platforms do support 32bit binaries too, the plan
to fix the code for 64bits has been cancelled.
I'm using gcc to build the application on all the target unices,
as well as autotools for build management.
As I'm building the toolchain myself too, I configure it with the
32bit host triplet on each platform, usually disabling multilib.
This simply works for ppc-aix, hppa-hpux, ia64-hpux, sparc-solaris,
x86-solaris, even if the underlying OS/kernel is 64bit.
It isn't even necessary to explicitly use --{build,host} at all,
as config.guess tells the 32bit triplet on these platforms.
Additionally, even their default compiler output is 32bit.
But Linux "is not Unix":
Configuring both binutils and gcc needs to be done with:
$ CC="gcc -m32" /path/to/configure --{build,host}=i686-pc-linux-gnu ...
This works on 64bit RHEL as well as on 64bit SLES (both have 32bit in /lib,
64bit in /lib64, no /lib32), but breaks on amd64+multilib Gentoo Linux.
Problem is that, as x86-linux isn't a multilib target, both ld and gcc
search for 32bit libs&objects in /usr/lib:/lib, as they don't know about
/usr/lib32:/lib32. The error when bootstrapping gcc is:
/usr/lib/crti.o: file not recognized: File format not recognized
While it is possible to patch binutils[1] and gcc[2] to search in
/usr/lib32:/lib32 even with this otherways non-multilib target,
it doesn't feel like the "right thing" to enable multilib for
just one multilib option.
Isn't the intention of multilib to have a new (64bit) system
be compatible with the corresponding old (32bit) system?
Please comment, thank you!
/haubi/
[1] http://overlays.gentoo.org/proj/alt/changeset/51324
[2] http://overlays.gentoo.org/proj/alt/changeset/51325
