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 User

 
 
LinkBack Thread Tools
 
Old 09-08-2012, 12:54 PM
"Roland Häder"
 
Default Aw: Some essential packages fail to compile

> > Isn't it a requirement that all nodes run Gentoo, with the same GCC
> version, and you must setup sys-devel/crossdev on each of them?
>
> I don't see how it could possibly work otherwise.
>

In my first email I wrote that all other nodes have Debian installed, not Gentoo.
 
Old 09-08-2012, 01:23 PM
"Roland Häder"
 
Default Aw: Some essential packages fail to compile

> > > Isn't it a requirement that all nodes run Gentoo, with the same GCC
> > version, and you must setup sys-devel/crossdev on each of them?
> >
> > I don't see how it could possibly work otherwise.
> >
I see the same thing. The next text block I wrote that I have Debian 64 bits (aka AMD64) on all other nodes and it is always possible to compile 32 bit programs/lib/whatever on 64 bit host system. That is called cross-compiling. The named package "crossdev" is NOT available on Debian systems and so I wont uninstall my Debian AMD64 on all other nodes only to compile 32 bits, there must be an other way.

One way is (if you have read any 'environment' files in my tar archive) to set the guest architecture explitcitly in /etc/(portage/)make.conf which I did.

That will tell every compiler (if provided by call parameters) to use the right architecture explicitly and that will always allow to compile 32 bit on 64 bit host systems. To say it again, this is already done on my Gentoo's /etc/(portage/)make.conf file and I quote the relevant parts for you again:

/etc/make.conf:
CFLAGS="-O2 -march=i686 -pipe -fPIC -m32"
CXXFLAGS="${CFLAGS}"
CHOST="i486-pc-linux-gnu"

I left the default CHOST as is and on the Debian systems I provided the required compiler.

Here is an example which I try to explain:
--------------------------
/usr/lib/gcc/i486-pc-linux-gnu/4.5.3/../../../../i486-pc-linux-gnu/bin/ld: i386:x86-64 architecture of input file `scripts/kconfig/conf.o' is incompatible with i386 output
--------------------------

One of the nodes has compiled a 64 bit object (conf.o) which the linker (running on 32 bit) tried to link to a 32 bit program/library (the output).

So for me, the Makefile in that package (klibc) didn't provide the specified CFLAGS I configured which needs fixing, if my assuming is right. I can deeper more investigate here.

From that same package' Makefile (found in /var/tmp/portage/bla/blub/work/ directory):

export HOSTCFLAGS := -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer

I think this line only needs to be extended with $(CFLAGS) then the fix is complete.

All other packages have same symtomes (missing $CLFAGS from /etc/make.conf) and can be fixed in similar or same way.

Regards,
Roland
 
Old 09-08-2012, 01:44 PM
Nikos Chantziaras
 
Default Aw: Some essential packages fail to compile

On 08/09/12 15:54, "Roland Häder" wrote:

Isn't it a requirement that all nodes run Gentoo, with the same GCC

version, and you must setup sys-devel/crossdev on each of them?

I don't see how it could possibly work otherwise.



In my first email I wrote that all other nodes have Debian installed, not Gentoo.


I was reading this:

http://www.gentoo.org/doc/en/cross-compiling-distcc.xml

It specifically mentions you need crossdev:

If you are cross-compiling between different subarchitectures
for Intel x86 (e.g. i586 and i686), you must still build a full
cross-toolchain for the desired CHOST, or else the compilation
will fail.

I suppose any cross compiler might be enough and you don't need
crossdev. I don't know.
 
Old 09-08-2012, 02:03 PM
"Roland Häder"
 
Default Aw: Some essential packages fail to compile

>
> I was reading this:
>
> http://www.gentoo.org/doc/en/cross-compiling-distcc.xml
I also read it far before I wrote my email.

>
> It specifically mentions you need crossdev:
>
> If you are cross-compiling between different subarchitectures
> for Intel x86 (e.g. i586 and i686), you must still build a full
> cross-toolchain for the desired CHOST, or else the compilation
> will fail.
>
> I suppose any cross compiler might be enough and you don't need
> crossdev. I don't know.
I need to repeat: The other nodes are all running Debian and there is *no* crossdev package. And I wrote in my initial mail, that I was already able to cross-compile other Gentoo packages on these nodes as the parameters -m32 and -march=i686 were *provided* by those packages which seems to be *not* the case with e.g. klibc

All I want is that the klibc package is honoring the global CFLAGS or else I have to temporary disable distcc (FEATURES variable needs to be commented out) for klibc, emerge klibc and then re-enable distcc to have a great speedup for other packages (that are honoring CFLAGS from make.conf).

I do that now what I wrote but it is really annoying to cannot leave the compilation unattended. I repeat once more: cross-compiling is possible on my nodes, so there is absolutely no need to setup such "cross-toolchains" because it works.
 
Old 09-08-2012, 07:37 PM
Andrea Conti
 
Default Aw: Some essential packages fail to compile

> One way is (if you have read any 'environment' files in my tar archive) to set the guest architecture explitcitly in /etc/(portage/)make.conf which I did.
>
> /etc/make.conf:
> CFLAGS="-O2 -march=i686 -pipe -fPIC -m32"
> CXXFLAGS="${CFLAGS}"
> CHOST="i486-pc-linux-gnu"

That is not "setting the guest architecture explicitly", you're just
telling whatever compiler gets invoked on the remote host to produce
32-bit output.

Cross-compiling with distcc is quite straightforward. As long as distcc
is setup correctly on the client (which for cross-compiling involves a
manual step, see below), and as long as the ebuilds properly invoke the
compiler with the CHOST prefix (i.e. 'i486-pc-linux-gnu-gcc' instead of
'gcc'), the appropriate compiler will be called on the servers, with no
need to manually play with your CFLAGS.

If you need -m32, it means you are *not* cross-compiling, i.e. you are
invoking the native gcc on the remote hosts instead of your
cross-compiler. That usually works as any x86_84 gcc with multilib
support can produce 32-bit output, but it is just masking the problem
and will break if the -m32 flag is lost for some reason.

> I left the default CHOST as is and on the Debian systems I provided the required compiler.

"provided the required compiler" should mean that on every server you
have a complete 32-bit toolchain (binutils, gcc, glibc and kernel
headers) with the version of each component matching those on your
distcc client. You should be able to compile a 32-bit executable locally
on any of the Debian systems just by invoking 'i486-pc-linux-gnu-gcc'.

Setting up such a toolchain can be quite a PITA, so on Gentoo it's
usually done with crossdev -- but as long as you get things right that's
not a requirement.

> One of the nodes has compiled a 64 bit object (conf.o) which the linker (running on 32 bit) tried to link to a 32 bit program/library (the output).
> So for me, the Makefile in that package (klibc) didn't provide the specified CFLAGS I configured which needs fixing, if my assuming is right. I can deeper more investigate here.
> export HOSTCFLAGS := -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
> I think this line only needs to be extended with $(CFLAGS) then the fix is complete.

No. CFLAGS are for the build target, HOSTCFLAGS are for the build host.
Building (configuring, actually) klibc involves compiling a tool which
is run on the host (i.e. the machine you're building on), before
compiling klibc itself for the build target.
In your case both the host and the target are the same
(i486-pc-linux-gnu), so the difference might not be very clear, but if
you were compiling klibc for a different arch (e.g. powerpc) you would
have a completely different build target, with its set of CFLAGS.

Back to your problem, the klibc build is correctly picking up your HOSTCC:

>>>> Source unpacked in /var/tmp/portage/dev-libs/klibc-1.5.20/work
>>>> Compiling source in /var/tmp/portage/dev-libs/klibc-1.5.20/work/klibc-1.5.20 ...
> make -j6 defconfig CC=i486-pc-linux-gnu-gcc HOSTCC=i486-pc-linux-gnu-gcc

but distcc seems to be invoking the native x86_64 compiler (i.e. 'gcc')
on the remote systems (you can also see all those warnings about
differing integer and pointer sizes).

My guess is that you didn't set up properly distcc for cross-compiling
on your client. Try following the instructions at

http://www.gentoo.org/doc/en/cross-compiling-distcc.xml

and let us know if it fixes your problem.

HTH,
andrea
 
Old 09-08-2012, 07:54 PM
Nikos Chantziaras
 
Default Aw: Some essential packages fail to compile

On 08/09/12 17:03, "Roland Häder" wrote:





I was reading this:

http://www.gentoo.org/doc/en/cross-compiling-distcc.xml

I also read it far before I wrote my email.



It specifically mentions you need crossdev:

If you are cross-compiling between different subarchitectures
for Intel x86 (e.g. i586 and i686), you must still build a full
cross-toolchain for the desired CHOST, or else the compilation
will fail.

I suppose any cross compiler might be enough and you don't need
crossdev. I don't know.

I need to repeat: The other nodes are all running Debian and there is *no* crossdev package. And I wrote in my initial mail, that I was already able to cross-compile other Gentoo packages on these nodes as the parameters -m32 and -march=i686 were *provided* by those packages which seems to be *not* the case with e.g. klibc

All I want is that the klibc package is honoring the global CFLAGS or else I have to temporary disable distcc (FEATURES variable needs to be commented out) for klibc, emerge klibc and then re-enable distcc to have a great speedup for other packages (that are honoring CFLAGS from make.conf).

I do that now what I wrote but it is really annoying to cannot leave the compilation unattended. I repeat once more: cross-compiling is possible on my nodes, so there is absolutely no need to setup such "cross-toolchains" because it works.


I'd say it worked for you by accident (because of multilib). But I
doubt this is supposed to actually work that way.
 
Old 09-08-2012, 08:43 PM
"Roland Häder"
 
Default Aw: Some essential packages fail to compile

> > CFLAGS="-O2 -march=i686 -pipe -fPIC -m32"
> > CXXFLAGS="${CFLAGS}"
> > CHOST="i486-pc-linux-gnu"
I have reformated my disk because I missed a parameter (-d . or so) which would make it possible for dracut to use gpg key decryption. Now I have to reinstall all from scratch (including configuring kernel). In the meanwhile I figured out that I choosed the wrong stage3 file (i486 instead of i686) (I have downloaded http://de-mirror.org/gentoo/releases/x86/current-stage3/stage3-i686-20120710.tar.bz2 + http://de-mirror.org/gentoo/snapshots/portage-latest.tar.bz2 now) which I could fix now. So now CHOST="i686-pc-linux-gnu" is set.

> That is not "setting the guest architecture explicitly", you're just
> telling whatever compiler gets invoked on the remote host to produce
> 32-bit output.
Guest from the other node's view. Okay, to stop confusion:

Node name | Distri | Architecture
------------------------------------------------------------
daedalus | Debian Unstable | AMD64 (with multilib support)
router | Debian Unstable | AMD64 (same)
laptop | Gentoo | x86 (i686, reinstallation)
------------------------------------------------------------

One think I also need that 'daedalus' or 'router' can start 64 and 32 bit compilations (e.g. wine should be better 32 bit, other games I play with are 64 bit compiled) which I would like to have. Most of these build systems sadly (!) call gcc and g++ (both aliases), so I had to add -m32 for 32 bit apps/libs.

If I fully follow that wiki page (I did until the wrapper script is added) I would have to change these links:

lrwxrwxrwx 1 root root 16 Sep 6 21:35 c++ -> ../../bin/distcc
lrwxrwxrwx 1 root root 16 Sep 6 21:35 cc -> ../../bin/distcc
lrwxrwxrwx 1 root root 16 Sep 6 21:35 g++ -> ../../bin/distcc
lrwxrwxrwx 1 root root 16 Sep 6 21:35 gcc -> ../../bin/distcc

... to the wrapper scripts which (I think so) will make it impossible to compile 64 bits.

In my view my "fix" by adding explicitly the -m32 -march=xxxx flags may help here better, as long as all packages are honoring them (which most do, except those with x86_64 problems).

> If you need -m32, it means you are *not* cross-compiling, i.e. you are
> invoking the native gcc on the remote hosts instead of your
> cross-compiler. That usually works as any x86_84 gcc with multilib
> support can produce 32-bit output, but it is just masking the problem
> and will break if the -m32 flag is lost for some reason.
Yes, i686-pc-linux-gnu-gcc and i686-pc-linux-gnu-g++ are just symbolic links to the native compilers (because I don't have those binaries).

Here is a list:
------------------------------------------------------
daedalus:/usr/bin# ls -l i686-pc-linux-gnu-g*
lrwxrwxrwx 1 root root 7 Sep 8 18:55 i686-pc-linux-gnu-g++ -> g++-4.7
lrwxrwxrwx 1 root root 7 Sep 8 18:55 i686-pc-linux-gnu-gcc -> gcc-4.7
------------------------------------------------------

I have now the g++-multilib and gcc-multilib packages installed on 'daedalus' and 'router', what now? They only contain libraries.

Should I better remove the symbolic links and add scripts there which adds -m32 -march=i686 to the parameter list (I could do it because those compiler names are only used on 'laptop').

Roland

>
> > I left the default CHOST as is and on the Debian systems I provided the required compiler.
>
> "provided the required compiler" should mean that on every server you
> have a complete 32-bit toolchain (binutils, gcc, glibc and kernel
> headers) with the version of each component matching those on your
> distcc client. You should be able to compile a 32-bit executable locally
> on any of the Debian systems just by invoking 'i486-pc-linux-gnu-gcc'.
>
> Setting up such a toolchain can be quite a PITA, so on Gentoo it's
> usually done with crossdev -- but as long as you get things right that's
> not a requirement.
>
> > One of the nodes has compiled a 64 bit object (conf.o) which the linker (running on 32 bit) tried to link to a 32 bit program/library (the output).
> > So for me, the Makefile in that package (klibc) didn't provide the specified CFLAGS I configured which needs fixing, if my assuming is right. I can deeper more investigate here.
> > export HOSTCFLAGS := -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
> > I think this line only needs to be extended with $(CFLAGS) then the fix is complete.
>
> No. CFLAGS are for the build target, HOSTCFLAGS are for the build host.
> Building (configuring, actually) klibc involves compiling a tool which
> is run on the host (i.e. the machine you're building on), before
> compiling klibc itself for the build target.
So CFLAGS and HOSTCFLAGS must be set to the same in make.conf? It is really confusing.

> In your case both the host and the target are the same
> (i486-pc-linux-gnu), so the difference might not be very clear, but if
> you were compiling klibc for a different arch (e.g. powerpc) you would
> have a completely different build target, with its set of CFLAGS.
I used the lines from default gentoo installation and only added "-fPIC -m32".


> and let us know if it fixes your problem.
Okay.

Roland
 
Old 09-08-2012, 08:44 PM
"Roland Häder"
 
Default Aw: Some essential packages fail to compile

> $ FEATURES=-distcc emerge klibc
Thanks.

Roland
 

Thread Tools




All times are GMT. The time now is 10:05 AM.

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