Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

2008-04-17 Thread Denys Vlasenko 
On Thursday 17 April 2008 05:26, Brian Dessent wrote:
 Denys Vlasenko wrote:
 
  Only in my case, $prefix contain neither as nor ld. gcc lives in
 
 Okay, so prepend /usr/app/binutils-2.18-x86_64-linux-uclibc/bin to PATH
 and gcc will find and use x86_64-linux-uclibc-{as,ld} without any of
 --with-{as,ld}.

It will remember the path?
What will happen when I install binutils-2.19
into /usr/app/binutils-2.19-x86_64-linux-uclibc sometime later?

I strongly prefer gcc to use my public x86_64-linux-uclibc-ld,
which is accessible by just searching PATH.

By searching PATH gcc doesn't even need to know how exactly it is done -
by adding /usr/app/binutils-2.19-x86_64-linux-uclibc/bin
to PATH or by creating /usr/bin/x86_64-linux-uclibc-ld symlink.
No ad-hoc, gcc-specific searching is needed, execvp already does
that searching in a standard, well-known way.
This wheel is already invented.

Currently, gcc insists on knowing full path to executable.
It's a policy decision. It narrows down the options.
Policy decisions are best left to humans,
while programs should just provide capabilities.

  it's much better for sanity that way.
 
 I would argue that it's not, since simply using the same $prefix
 JustWorks(tm) without worrying about modifying PATH or any --with-foo.

Using the same $prefix requires one to remeber which versions
of binutils+gcc+whatever are installed into same $prefix,
and God knows how exactly they will stomp on each other's
toes (files) there.

IMO, of course.
--
vda

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

2008-04-16 Thread Daniel Jacobowitz 
On Tue, Apr 15, 2008 at 05:34:17AM +0200, Denys Vlasenko wrote:
 --bindir=/usr/bin   \

 bindir=$STATIC/bin  \

Why are you configuring for one set of paths which are half in $STATIC
and half in /usr, and installing in paths which are all in $STATIC?

That's causing this:

 30816 
 stat64(/.share/usr/app/gcc-4.3.0-i486-linux-uclibc/bin/../app/gcc-4.3.0-i486-linux-uclibc/libexec/gcc/i486-linux-uclibc/4.3.0/cc1,
  0xffde613c) = -1 ENOENT (No such file or directory)

At this point it's clear something is wrong.  The libexec directory is
not in the same relation to bindir that it was at configure time.
You've moved parts of the toolchain pretty much arbitrarily, so it's
not surprising at all to me that it can't find itself...

-- 
Daniel Jacobowitz
CodeSourcery

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

2008-04-16 Thread Denys Vlasenko 
On Wednesday 16 April 2008 16:23, Daniel Jacobowitz wrote:
 On Tue, Apr 15, 2008 at 05:34:17AM +0200, Denys Vlasenko wrote:
  --bindir=/usr/bin   \
 
  bindir=$STATIC/bin  \
 
 Why are you configuring for one set of paths which are half in $STATIC
 and half in /usr, and installing in paths which are all in $STATIC?

Because I install gcc into /usr/app/gcc-N.N.N-target/{bin,lib,whatever}
and then I create links for every binary in bin/*

/usr/bin/foo - /usr/app/gcc-N.N.N-target/foo

Same for lib/* etc.

I do it not not only for gcc but for almost everything.

I discovered that a lot of packages will remember patchs given
to configure and use those at runtime. I want them to use
/ust/bin/something rather than /usr/app/bar/bin/something.

I found that usually giving bindir=/usr/bin to configure
but giving bindir=/usr/app/bar/bin to make install will do the trick.

 That's causing this:
 
  30816 
  stat64(/.share/usr/app/gcc-4.3.0-i486-linux-uclibc/bin/../app/gcc-4.3.0-i486-linux-uclibc/libexec/gcc/i486-linux-uclibc/4.3.0/cc1,
   0xffde613c) = -1 ENOENT (No such file or directory)
 
 At this point it's clear something is wrong.  The libexec directory is
 not in the same relation to bindir that it was at configure time.

Yes, I see... I will try giving bindir=/usr/app/gcc-N.N.N-target/bin
to configure. Will let you know if it still doesn't work.

 You've moved parts of the toolchain pretty much arbitrarily, so it's
 not surprising at all to me that it can't find itself...

Maybe gcc can use paths relative to executable's location?
readlink(/proc/self/exe) and all that.
It will make gcc installation movable without rebuilding.

(Actually it's my biggest gripe about the way Linux packages
are built: generally you can't move them
and expect them to work).
--
vda

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

2008-04-16 Thread Daniel Jacobowitz 
On Wed, Apr 16, 2008 at 05:21:55PM +0200, Denys Vlasenko wrote:
 Maybe gcc can use paths relative to executable's location?
 readlink(/proc/self/exe) and all that.
 It will make gcc installation movable without rebuilding.

It already does.  That's exactly what the code causing you a problem
is for.  So if you don't try to work around the lack of a feature
which is in fact present, everything will just work :-)

It's configured to live in /usr/bin.  So from there it searches
../app*/lib/gcc/wherever to find cc1.  When it discovers that you ran
it from /usr/app*/bin instead (by following the symlink to the real
binary), it searches /usr/app*/bin/../app*/lib/gcc/wherever.  But
cc1's not there.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

2008-04-16 Thread Denys Vlasenko 
On Wednesday 16 April 2008 17:43, Daniel Jacobowitz wrote:
 On Wed, Apr 16, 2008 at 05:21:55PM +0200, Denys Vlasenko wrote:
  Maybe gcc can use paths relative to executable's location?
  readlink(/proc/self/exe) and all that.
  It will make gcc installation movable without rebuilding.
 
 It already does.  That's exactly what the code causing you a problem
 is for.  So if you don't try to work around the lack of a feature
 which is in fact present, everything will just work :-)
 
 It's configured to live in /usr/bin.  So from there it searches
 ../app*/lib/gcc/wherever to find cc1.  When it discovers that you ran
 it from /usr/app*/bin instead (by following the symlink to the real
 binary), it searches /usr/app*/bin/../app*/lib/gcc/wherever.  But
 cc1's not there.

Cool! Giving it a try...



Meanwhile: I decided to get rid of paths in as/ld invocations
by specifying as/ld names without any paths:

--with-gnu-ld   \
--with-ld=$CROSS-ld   \
--with-gnu-as   \
--with-as=$CROSS-as   \

and it works, I only need to patch configure to not test x $with_ld
as that won't work.

I tested in and it works.

The patch is below. Do you think it makes sense?
--
vda

--- gcc-4.2.3.org/gcc/configure	Sun Sep 23 23:08:04 2007
+++ gcc-4.2.3/gcc/configure	Tue Apr 15 07:35:57 2008
@@ -1751,11 +1751,7 @@
   DEFAULT_LINKER=$with_ld
 fi;
 if test x${DEFAULT_LINKER+set} = xset; then
-  if test ! -x $DEFAULT_LINKER; then
-{ { echo $as_me:$LINENO: error: cannot execute: $DEFAULT_LINKER: check --with-ld or env. var. DEFAULT_LINKER 5
-echo $as_me: error: cannot execute: $DEFAULT_LINKER: check --with-ld or env. var. DEFAULT_LINKER 2;}
-   { (exit 1); exit 1; }; }
-  elif $DEFAULT_LINKER -v  /dev/null 21 | grep GNU  /dev/null; then
+  if $DEFAULT_LINKER -v  /dev/null 21 | grep GNU  /dev/null; then
 gnu_ld_flag=yes
   fi
 
@@ -1811,11 +1807,7 @@
   DEFAULT_ASSEMBLER=$with_as
 fi;
 if test x${DEFAULT_ASSEMBLER+set} = xset; then
-  if test ! -x $DEFAULT_ASSEMBLER; then
-{ { echo $as_me:$LINENO: error: cannot execute: $DEFAULT_ASSEMBLER: check --with-as or env. var. DEFAULT_ASSEMBLER 5
-echo $as_me: error: cannot execute: $DEFAULT_ASSEMBLER: check --with-as or env. var. DEFAULT_ASSEMBLER 2;}
-   { (exit 1); exit 1; }; }
-  elif $DEFAULT_ASSEMBLER -v  /dev/null 21 | grep GNU  /dev/null; then
+  if $DEFAULT_ASSEMBLER -v  /dev/null 21 | grep GNU  /dev/null; then
 gas_flag=yes
   fi

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

2008-04-16 Thread Daniel Jacobowitz 
On Wed, Apr 16, 2008 at 09:01:44PM +0200, Denys Vlasenko wrote:
 As I mentined in the first mail, it's not the end of a story.
 Next issue: can't find header files. This used to work with 4.2.1:

Try -v to see where it is searching.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

2008-04-16 Thread Denys Vlasenko 
On Wednesday 16 April 2008 21:17, Daniel Jacobowitz wrote:
 On Wed, Apr 16, 2008 at 09:01:44PM +0200, Denys Vlasenko wrote:
  As I mentined in the first mail, it's not the end of a story.
  Next issue: can't find header files. This used to work with 4.2.1:
 
 Try -v to see where it is searching.

4.2.1 says:

#include ... search starts here:
#include ... search starts here:
 include
 libbb
 
/.share/usr/app/gcc-4.2.3-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.2.3/include
 /usr/lib/../x86_64-linux-uclibc/include
End of search list.

4.3.0 says:

#include ... search starts here:
#include ... search starts here:
 include
 libbb
 
/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/include
 
/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/include-fixed
End of search list.


--
vda

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

2008-04-16 Thread Denys Vlasenko 
On Wednesday 16 April 2008 21:59, Daniel Jacobowitz wrote:
 On Wed, Apr 16, 2008 at 09:55:09PM +0200, Denys Vlasenko wrote:
  #include ... search starts here:
  #include ... search starts here:
   include
   libbb
   
  /.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/include
   
  /.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/include-fixed
  End of search list.
 
 Read the rest of it, to find the directories it skipped.

Here is that part too:

ignoring nonexistent directory 
/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/../../../../x86_64-
linux-uclibc/sys-include
ignoring nonexistent directory 
/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/../../../../x86_64-
linux-uclibc/include
ignoring duplicate directory 
/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/../../lib/gcc/x86_64-linux-uclibc/4.3.0/include

ignoring duplicate directory 
/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/../../lib/gcc/x86_64-linux-uclibc/4.3.0/include
-fixed
ignoring nonexistent directory 
/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/../../lib/gcc/x86_64-linux-uclibc/4.3.0/../..
/../../x86_64-linux-uclibc/sys-include
ignoring nonexistent directory 
/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/../../lib/gcc/x86_64-linux-uclibc/4.3.0/../..
/../../x86_64-linux-uclibc/include
ignoring duplicate directory 
/.1/usr/srcdevel/bbox/fix/busybox.t8_64prime/libbb
#include ... search starts here:
#include ... search starts here:
 include
 libbb
 
/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/include
 
/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/include-fixed
End of search list.



It seems that 4.2.1 was testing /usr/lib/../x86_64-linux-uclibc/include,
i.e. $libdir/../x86_64-linux-uclibc/include. From the listing above
I see them 4.3.0 does not do that anymore - there is no
/../x86_64-linux-uclibc/include... or maybe there is, in the form of:
xxx/../lib/gcc/x86_64-linux-uclibc/4.3.0/../../../../x86_64-linux-uclibc/include

(Is it necessary to do this /../../../../ thing?)

Anyway, by now I feel it can be much easier if configure had
a parameter for updating default include path.

 I assume this is another problem of your mixed configure options.
 It's probably relocating the header search dir and you're leaving it
 unrelocated in your installation.

But now I don't have mixed configure options anymore, they all point
to /usr/app/gcc-4.3.0-x86_64-linux-uclibc[/bin etc], as you suggested:

configure invocation was:

STATIC=/usr/app/gcc-4.3.0-x86_64-linux-uclibc

$SRC/configure \
--prefix=$STATIC\
--exec-prefix=$STATIC   \
--bindir=$STATIC/bin\
--sbindir=$STATIC/sbin  \
--libexecdir=$STATIC/libexec\
--datadir=$STATIC/share \
--sysconfdir=/etc   \
--sharedstatedir=$STATIC/var/com\
--localstatedir=$STATIC/var \
--libdir=$STATIC/lib\
--includedir=$STATIC/include\
--infodir=$STATIC/info  \
--mandir=$STATIC/man\
\
--disable-nls   \
\
--with-local-prefix=/usr/local  \
--with-slibdir=$STATIC/lib  \
--with-gxx-include-dir=$STATIC/include/g++-v3   \
\
--build=i386-pc-linux-gnu   \
--host=i386-pc-linux-gnu\
--target=$CROSS \
\
--with-gnu-ld   \
--with-ld=$CROSS-ld   \
--with-gnu-as   \
--with-as=$CROSS-as   \
\
--enable-languages=c,c++  \
--enable-target-optspace\
--disable-shared\
--disable-__cxa_atexit  \
--disable-threads   \
--disable-tls   \
--disable-multilib  \
--without-headers   \

make invocation was:

make \
prefix=$STATIC  \
exec-prefix=$STATIC \
bindir=$STATIC/bin  \
sbindir=$STATIC/sbin\
libexecdir=$STATIC/libexec  \
datadir=$STATIC/share   \
sysconfdir=$STATIC/var/etc  \
sharedstatedir=$STATIC/var/com  \
localstatedir=$STATIC/var   \
libdir=$STATIC/lib  \
includedir=$STATIC/include  \
infodir=$STATIC/info\
mandir=$STATIC/man  \
\
install-gcc

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

2008-04-16 Thread Daniel Jacobowitz 
On Wed, Apr 16, 2008 at 10:24:35PM +0200, Denys Vlasenko wrote:
 It seems that 4.2.1 was testing /usr/lib/../x86_64-linux-uclibc/include,
 i.e. $libdir/../x86_64-linux-uclibc/include. From the listing above
 I see them 4.3.0 does not do that anymore - there is no
 /../x86_64-linux-uclibc/include... or maybe there is, in the form of:
 xxx/../lib/gcc/x86_64-linux-uclibc/4.3.0/../../../../x86_64-linux-uclibc/include

Correct.  A relocated GCC 4.2.1 installation would still search
various directories in their unrelocated paths.  This was a bug and
I'm sorry to hear that fixing it broke your setup.  It could cause all
sorts of problems when you have two versions of GCC installed.

The documented (well, I think it is?) directory being searched here is
$exec_prefix/$target/include.

 (Is it necessary to do this /../../../../ thing?)

Yes, because that's how the directories are found.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

2008-04-16 Thread Denys Vlasenko 
On Thursday 17 April 2008 00:42, Daniel Jacobowitz wrote:
 On Wed, Apr 16, 2008 at 10:24:35PM +0200, Denys Vlasenko wrote:
  It seems that 4.2.1 was testing /usr/lib/../x86_64-linux-uclibc/include,
  i.e. $libdir/../x86_64-linux-uclibc/include. From the listing above
  I see them 4.3.0 does not do that anymore - there is no
  /../x86_64-linux-uclibc/include... or maybe there is, in the form of:
  xxx/../lib/gcc/x86_64-linux-uclibc/4.3.0/../../../../x86_64-linux-uclibc/include
 
 Correct.  A relocated GCC 4.2.1 installation would still search
 various directories in their unrelocated paths.  This was a bug and
 I'm sorry to hear that fixing it broke your setup.  It could cause all
 sorts of problems when you have two versions of GCC installed.

I believe I solved it with --with-sysroot, and then met yet another problem:
4.3.0 tried to link in different crtXXX.o files (those which do not exist
on my system). Will try again and let you know.

 The documented (well, I think it is?) directory being searched here is
 $exec_prefix/$target/include.
 
  (Is it necessary to do this /../../../../ thing?)
 
 Yes, because that's how the directories are found.

Well, it looks like the path like

xxx/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/../../../../x86_64-linux-uclibc/include

is equivalent to simply xxx/x86_64-linux-uclibc/include, sans cases
where one of those directories (which we go into only to go out again)
does not exist. Hmm. Maybe symlinks may make it more complex. Oh well.
--
vda

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

2008-04-16 Thread Denys Vlasenko 
On Thursday 17 April 2008 02:40, Denys Vlasenko wrote:
 I believe I solved it with --with-sysroot...
 Will try again and let you know.

So far I only discovered that --with-as=$CROSS-as is not going to work.
Fixing configure is not enough:

23651 access(x86_64-linux-uclibc-as, X_OK) = -1 ENOENT (No such file or 
directory)
Why? You can just try execvp'ing (instead of access()),
and only if that fails, go try other variants...
23651 
stat64(/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../libexec/gcc/x86_
23651 
stat64(/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../libexec/gcc/as,
23651 
stat64(/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-l
23651 
stat64(/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-l
23651 vfork()   = 23653
23653 execve(/usr/bin/as, [as, -v, -Iinclude, -Ilibbb, 
-I/.1/usr/srcdev

and *this* as, being native one, makes 32-bit .o files. :(

What happened to the good old concept of looking up executables'
location in $PATH if they have no slashes on the name?

(Oh well)^2. Recompiling with --with-as=/usr/bin/$CROSS-as...
--
vda

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

2008-04-16 Thread Brian Dessent 
Denys Vlasenko wrote:

 (Is it necessary to do this /../../../../ thing?)

A useful trick to make this easier for a human to read is to pipe the
output through

sed -e :a -e s,[^/]*/\.\.\/,, -e ta

I don't guarantee that this will always result in the correct semantics
in all situations but it's not too far off.  readlink -m would be
closer if needed.

Denys Vlasenko wrote:

 What happened to the good old concept of looking up executables'
 location in $PATH if they have no slashes on the name?
 
 (Oh well)^2. Recompiling with --with-as=/usr/bin/$CROSS-as...

Why do you think it's necessary to specify this?  Configure will
automatically find and use $tooldir/bin/as (= $prefix/$target/bin/as) or
$target-as in PATH.

Brian

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

2008-04-16 Thread Denys Vlasenko 
On Thursday 17 April 2008 03:35, Denys Vlasenko wrote:
 On Thursday 17 April 2008 02:40, Denys Vlasenko wrote:
  I believe I solved it with --with-sysroot...
  Will try again and let you know.

I got over the problem of includes not being found using --with-sysroot,
and reached
/usr/bin/x86_64-linux-uclibc-ld: crtbegin.o: No such file: No such file or 
directory
problem.

This is the final link command I use:

x86_64-linux-uclibc-gcc -v -Wall -Wshadow -Wwrite-strings -Wundef  \
-Wstrict-prototypes -Wunused -Wunused-parameter -Werror -Wold-style-definition  
\
-Os -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer  \
-ffunction-sections -fdata-sections -fno-guess-branch-probability  \
-funsigned-char -static-libgcc -falign-functions=1 -falign-jumps=1  \
-falign-labels=1 -falign-loops=1 -Wdeclaration-after-statement  \
-Wno-pointer-sign -o busybox_unstripped -Wl,--sort-common -Wl,--gc-sections  \
-Wl,--start-group applets/built-in.o archival/lib.a archival/libunarchive/lib.a 
 \
console-tools/lib.a coreutils/lib.a coreutils/libcoreutils/lib.a  \
debianutils/lib.a e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a  \
libbb/lib.a libpwdgrp/lib.a loginutils/lib.a miscutils/lib.a modutils/lib.a  \
networking/lib.a networking/libiproute/lib.a networking/udhcp/lib.a  \
printutils/lib.a procps/lib.a runit/lib.a selinux/lib.a shell/lib.a  \
sysklogd/lib.a util-linux/lib.a util-linux/volume_id/lib.a archival/built-in.o  
\
archival/libunarchive/built-in.o console-tools/built-in.o coreutils/built-in.o  
\
coreutils/libcoreutils/built-in.o debianutils/built-in.o e2fsprogs/built-in.o  \
editors/built-in.o findutils/built-in.o init/built-in.o libbb/built-in.o  \
libpwdgrp/built-in.o loginutils/built-in.o miscutils/built-in.o  \
modutils/built-in.o networking/built-in.o networking/libiproute/built-in.o  \
networking/udhcp/built-in.o printutils/built-in.o procps/built-in.o  \
runit/built-in.o selinux/built-in.o shell/built-in.o sysklogd/built-in.o  \
util-linux/built-in.o util-linux/volume_id/built-in.o -Wl,--end-group  \
-Wl,--start-group -lcrypt -lm -Wl,--end-group

4.2.3 works:

Using built-in specs.
Target: x86_64-linux-uclibc
Configured with: ../gcc-4.2.3/configure 
--prefix=/usr/app/gcc-4.2.3-x86_64-linux-uclibc 
--exec-prefix=/usr/app/gcc-4.2.3-x86_64-linux-uclibc --bindir=/usr/bin 
--sbindir=/usr/sbin --libexecdir=/usr/app/gcc-4.2.3-x86_64-linux-uclibc/libexec 
--datadir=/usr/app/gcc-4.2.3-x86_64-linux-uclibc/share --sysconfdir=/etc 
--sharedstatedir=/usr/app/gcc-4.2.3-x86_64-linux-uclibc/var/com 
--localstatedir=/usr/app/gcc-4.2.3-x86_64-linux-uclibc/var --libdir=/usr/lib 
--includedir=/usr/include --infodir=/usr/info --mandir=/usr/man --disable-nls 
--with-local-prefix=/usr/local 
--with-slibdir=/usr/app/gcc-4.2.3-x86_64-linux-uclibc/lib 
--with-gxx-include-dir=/usr/app/gcc-4.2.3-x86_64-linux-uclibc/include/g++-v3 
--build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=x86_64-linux-uclibc 
--with-gnu-ld --with-ld=x86_64-linux-uclibc-ld --with-gnu-as 
--with-as=x86_64-linux-uclibc-as --enable-languages=c,c++ 
--enable-target-optspace --disable-shared --disable-__cxa_atexit 
--disable-threads --disable-tls --disable-multilib --without-headers
Thread model: single
gcc version 4.2.3
 
/usr/app/gcc-4.2.3-x86_64-linux-uclibc/libexec/gcc/x86_64-linux-uclibc/4.2.3/collect2
 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib/ld64-uClibc.so.0 -o 
busybox_unstripped /usr/lib/../x86_64-linux-uclibc/lib/crt1.o 
/usr/lib/../x86_64-linux-uclibc/lib/crti.o 
/.share/usr/app/gcc-4.2.3-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.2.3/crtbegin.o
 
-L/.share/usr/app/gcc-4.2.3-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.2.3
 -L/.share/usr/app/gcc-4.2.3-x86_64-linux-uclibc/bin/../lib/gcc 
-L/usr/lib/../x86_64-linux-uclibc/lib --sort-common --gc-sections --start-group 
applets/built-in.o archival/lib.a archival/libunarchive/lib.a 
console-tools/lib.a coreutils/lib.a coreutils/libcoreutils/lib.a 
debianutils/lib.a e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a 
libbb/lib.a libpwdgrp/lib.a loginutils/lib.a miscutils/lib.a modutils/lib.a 
networking/lib.a networking/libiproute/lib.a networking/udhcp/lib.a 
printutils/lib.a procps/lib.a runit/lib.a selinux/lib.a shell/lib.a 
sysklogd/lib.a util-linux/lib.a util-linux/volume_id/lib.a archival/built-in.o 
archival/libunarchive/built-in.o console-tools/built-in.o coreutils/built-in.o 
coreutils/libcoreutils/built-in.o debianutils/built-in.o e2fsprogs/built-in.o 
editors/built-in.o findutils/built-in.o init/built-in.o libbb/built-in.o 
libpwdgrp/built-in.o loginutils/built-in.o miscutils/built-in.o 
modutils/built-in.o networking/built-in.o networking/libiproute/built-in.o 
networking/udhcp/built-in.o printutils/built-in.o procps/built-in.o 
runit/built-in.o selinux/built-in.o shell/built-in.o sysklogd/built-in.o 
util-linux/built-in.o util-linux/volume_id/built-in.o --end-group --start-group 
-lcrypt -lm --end-group -lgcc -lc -lgcc

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

2008-04-16 Thread Denys Vlasenko 
On Thursday 17 April 2008 04:04, Brian Dessent wrote:
  What happened to the good old concept of looking up executables'
  location in $PATH if they have no slashes on the name?
  
  (Oh well)^2. Recompiling with --with-as=/usr/bin/$CROSS-as...
 
 Why do you think it's necessary to specify this?

I don't think that it is necessary. I find it useful.
It's useful in a following way:
if gcc will invoke as and ld by execvp(x86_64-linux-uclibc-as...),
I can trivially fix all cases where it calls wrong as/ld
by either installing working one or changing the $PATH.

*I can do it without recompiling gcc or having to put as/ld in some
obscure multi-level directories* - this is what I like the most.

 Configure will 
 automatically find and use $tooldir/bin/as (= $prefix/$target/bin/as) or
 $target-as in PATH.

Only in my case, $prefix contain neither as nor ld. gcc lives in

/usr/app/gcc-4.3.0-x86_64-linux-uclibc/*

while binutils lives in

/usr/app/binutils-2.18-x86_64-linux-uclibc/*

it's much better for sanity that way.
--
vda

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

2008-04-16 Thread Brian Dessent 
Denys Vlasenko wrote:

 Only in my case, $prefix contain neither as nor ld. gcc lives in

Okay, so prepend /usr/app/binutils-2.18-x86_64-linux-uclibc/bin to PATH
and gcc will find and use x86_64-linux-uclibc-{as,ld} without any of
--with-{as,ld}.

 it's much better for sanity that way.

I would argue that it's not, since simply using the same $prefix
JustWorks(tm) without worrying about modifying PATH or any --with-foo.

Brian

Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

2008-04-14 Thread Denys Vlasenko 
Ok, I give up.

I killed many hours trying to build a cross-compiling
x86_64-linux-uclibc-gcc, version 4.3.0.

After many WTF? moments I decided to go back and try
to build a cross-compiler which I already have,
just older version: I decided to build i486 one,
not x86_64.

Because I already have i486-linux-uclibc-gcc version 4.2.1
and it works.

I unpacked and built i486-linux-uclibc-gcc version 4.3.0
with absolutely the same configure and make command lines,
and it does not work. Specifically, it seems to mess up
paths:

i486-linux-uclibc-gcc: error trying to exec 'cc1': execvp: No such file or 
directory

stracing gcc invocation reveals typical 
..bin/../lib/something/../../../../../something-else/..
stuff, but this time, it definitely fails to pick up cc1.

(See below for strace comparison between 4.2.1 and 4.3.0)

Yeah, yeah, I saw it with x86_64-linux-uclibc-gcc too
and was able to overcome it with even more hacks and
options in configure, but it won't stop there!
It will use wrong as and/or ld; then it will also try
to link wrong crtX.o files which do not exist!

So I won't try to fix that now - instead, let's concentrate
on how in hell? it was working before!

Well, hrm last sanity check:

I remove i486-linux-uclibc-gcc version 4.2.1, unpack
fresh 4.2.1, build it with the very same configure and
make options and IT WORKS!

So, something definitely is changed incompatibly between 4.2.1 and 4.3.0

Help...


STATIC=/usr/app/gcc-4.3.0-i486-linux-uclibc

configure invocation:

../gcc-4.3.0/configure \
--prefix=$STATIC\
--exec-prefix=$STATIC   \
--bindir=/usr/bin   \
--sbindir=/usr/sbin \
--libexecdir=$STATIC/libexec\
--datadir=$STATIC/share \
--sysconfdir=/etc   \
--sharedstatedir=$STATIC/var/com\
--localstatedir=$STATIC/var \
--libdir=/usr/lib   \
--includedir=/usr/include   \
--infodir=/usr/info \
--mandir=/usr/man   \
\
--with-slibdir=$STATIC/lib  \
--disable-shared\
--with-local-prefix=/usr/local  \
--with-gxx-include-dir=$STATIC/include/g++-v3   \
--enable-languages=c,c++  \
--disable-nls   \
\
--build=i386-pc-linux-gnu   \
--host=i386-pc-linux-gnu\
--target=i486-linux-uclibc  \
\
--disable-__cxa_atexit  \
--enable-target-optspace\
--with-gnu-ld   \
--disable-threads   \
--disable-multilib  \
--without-headers   \

make invocation:

make all-gcc

make install invocation:

make \
prefix=$STATIC  \
exec-prefix=$STATIC \
bindir=$STATIC/bin  \
sbindir=$STATIC/sbin\
libexecdir=$STATIC/libexec  \
datadir=$STATIC/share   \
sysconfdir=$STATIC/var/etc  \
sharedstatedir=$STATIC/var/com  \
localstatedir=$STATIC/var   \
libdir=$STATIC/lib  \
includedir=$STATIC/include  \
infodir=$STATIC/info\
mandir=$STATIC/man  \
\
install-gcc

gcc 4.3.0 fails to find cc1:

30816 
stat64(/.share/usr/app/gcc-4.3.0-i486-linux-uclibc/bin/../app/gcc-4.3.0-i486-linux-uclibc/libexec/gcc/i486-linux-uclibc/4.3.0/cc1,
 0xffde613c) = -1 ENOENT (No such file or directory)
30816 
stat64(/.share/usr/app/gcc-4.3.0-i486-linux-uclibc/bin/../app/gcc-4.3.0-i486-linux-uclibc/libexec/gcc/cc1,
 0xffde613c) = -1 ENOENT (No such file or directory)
30816 
stat64(/.share/usr/app/gcc-4.3.0-i486-linux-uclibc/bin/../lib/gcc/i486-linux-uclibc/4.3.0/../../../../../i486-linux-uclibc/bin/i486-linux-uclibc/4.3.0/cc1,
 0xffde613c) = -1 ENOENT (No such file or directory)
30816 
stat64(/.share/usr/app/gcc-4.3.0-i486-linux-uclibc/bin/../lib/gcc/i486-linux-uclibc/4.3.0/../../../../../i486-linux-uclibc/bin/cc1,
 0xffde613c) = -1 ENOENT (No such file or directory)
30816 vfork()   = 30817
30817 execve(/root/bin/cc1, [cc1, -quiet, -Iinclude, -Ilibbb, 
-I/.1/usr/srcdevel/bbox/fix/busy..., -iprefix, 
/.share/usr/app/gcc-4.3.0-i486-l..., -D_GNU_SOURCE, -DNDEBUG, 
-D_LARGEFILE_SOURCE, -D_LARGEFILE64_SOURCE, -D_FILE_OFFSET_BITS=64, 
-DBB_VER=KBUILD_STR(1.11.0.svn), -DBB_BT=AUTOCONF_TIMESTAMP, 
-DKBUILD_STR(s)=#s, -DKBUILD_BASENAME=KBUILD_STR(app..., ...], [/* 35 vars 
*/]) = -1 ENOENT (No such file or directory)
30817 execve(/bin/cc1, [cc1, -quiet, -Iinclude, -Ilibbb, 
-I/.1/usr/srcdevel/bbox/fix/busy..., -iprefix, 
/.share/usr/app/gcc-4.3.0-i486-l..., -D_GNU_SOURCE, -DNDEBUG, 
-D_LARGEFILE_SOURCE, -D_LARGEFILE64_SOURCE, -D_FILE_OFFSET_BITS=64,