This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: native builds



Yann E. MORIN wrote:
> toolset-ng? I don't know about this...
> Are you speaking of crosstool-NG?

Yes, of course! ... so much tool here.

> First, it's under EXPERIMENTAL, so that the user really knows he/she
> is trying experimental features.
> 
> Second, it's marked as NO CODE because there is actually no code to
> build a "native" toolchain. The only code present detects this and
> bails out.

Thank you. I already guessed it, I just was hoping it could mean
"no code needed" (since its native) as oposed to "no code yet
available". ;-)

> So, in the state, it will not work.

Ok.

...

> First:
> What are you refering to by "running on the same host"?
> Are you saying the _compilers_ are to run on the same machine?
> Or do you mean that the compilers should _produce_ code that run on the
> same machine?

The compiler shall (be able to) run on the same machine for which it is
producing code. The biaries just should be linked to a different glibc.
(Does this make sense?)

> Second:
> What do you mean by "on the same host"?
> Are you saying that the machine the compilers produce code for is the
> same machine as the compilers run on?

Hmm, let me try to rephrase:
On my development machine I want to have several compilers (toolchains)
which are able to produce code that could run on my development machine
if I would install an older version of glibc.
(Not sure if this makes thing clearer.)

What I ultimately want to achieve is to have several compilers on
my box, so I can generate executables for customers who run systems
with different versions of glibc and/or linux-headers.
One of them hopefully be the mingw target, but I understand that mingw
is not feasasible yet.

...
> You could work this around using the "Vendor string" option (in the menu
> "Toolchain options"), and set it to something different from your host's
> tuple. Then you'd build a cross-compiler.

I tried this, and my
build  is i486-linux-gnu
host   is i486-linux-gnu and
target is i386-custom-linux-gnu

but during
[INFO ]  Installing shared core C compiler
I get:

[DEBUG]    ==> Executing: 'make -j1 -C gcc libgcc.mk'
[ALL  ]    make[1]: Entering directory
`/home/roland/projects/crosstool-ng/targets/i386-custom-linux-gnu/build/build-cc-core-shared/gcc'
[ALL  ]    TARGET_CPU_DEFAULT="" 	HEADERS="auto-host.h ansidecl.h"
DEFINES="" 	/bin/sh
/home/roland/projects/crosstool-ng/targets/src/gcc-4.0.4/gcc/mkconfig.sh
config.h
[ALL  ]    TARGET_CPU_DEFAULT="" 	HEADERS="config/i386/i386.h
config/i386/unix.h config/i386/att.h config/dbxelf.h config/elfos.h
config/svr4.h config/linux.h config/i386/linux.h defaults.h"
DEFINES="" 	/bin/sh
/home/roland/projects/crosstool-ng/targets/src/gcc-4.0.4/gcc/mkconfig.sh
tm.h
[ALL  ]    TARGET_CPU_DEFAULT="" 	HEADERS="auto-host.h ansidecl.h"
DEFINES="" 	/bin/sh
/home/roland/projects/crosstool-ng/targets/src/gcc-4.0.4/gcc/mkconfig.sh
bconfig.h
[ALL  ]    gcc -c   -g -DIN_GCC -DCROSS_COMPILE  -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wold-style-definition
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
-I/home/roland/projects/crosstool-ng/targets/src/gcc-4.0.4/gcc
-I/home/roland/projects/crosstool-ng/targets/src/gcc-4.0.4/gcc/build
-I/home/roland/projects/crosstool-ng/targets/src/gcc-4.0.4/gcc/../include
-I/home/roland/projects/crosstool-ng/targets/src/gcc-4.0.4/gcc/../libcpp/include
-I/home/roland/x-tools/i386-custom-linux-gnu/include
-I/home/roland/x-tools/i386-custom-linux-gnu/include    -o
build/genmodes.o
/home/roland/projects/crosstool-ng/targets/src/gcc-4.0.4/gcc/genmodes.c
[ALL  ]    gcc -c   -g -DIN_GCC -DCROSS_COMPILE  -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wold-style-definition
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
-I/home/roland/projects/crosstool-ng/targets/src/gcc-4.0.4/gcc
-I/home/roland/projects/crosstool-ng/targets/src/gcc-4.0.4/gcc/build
-I/home/roland/projects/crosstool-ng/targets/src/gcc-4.0.4/gcc/../include
-I/home/roland/projects/crosstool-ng/targets/src/gcc-4.0.4/gcc/../libcpp/include
-I/home/roland/x-tools/i386-custom-linux-gnu/include
-I/home/roland/x-tools/i386-custom-linux-gnu/include    -o
build/errors.o
/home/roland/projects/crosstool-ng/targets/src/gcc-4.0.4/gcc/errors.c
[ALL  ]    make[1]: *** No rule to make target
`../build-i486-build_pc-linux-gnu/libiberty/libiberty.a', needed by
`build/genmodes'.  Stop.
[ALL  ]    make[1]: Leaving directory
`/home/roland/projects/crosstool-ng/targets/i386-custom-linux-gnu/build/build-cc-core-shared/gcc'
[ERROR]    Build failed in step 'Installing shared core C compiler'
[ERROR]    Error happened in
'/home/roland/projects/crosstool-ng/scripts/functions' in function
'CT_DoExecLog' (line unknown, sorry)
[ERROR]          called from
'/home/roland/projects/crosstool-ng/scripts/build/cc/gcc.sh' at line #
203 in function 'do_cc_core'
[ERROR]          called from
'/home/roland/projects/crosstool-ng/scripts/build/cc/gcc.sh' at line #
60 in function 'do_cc_core_pass_2'
[ERROR]          called from
'/home/roland/projects/crosstool-ng/scripts/crosstool-NG.sh' at line #
481 in function 'main'
[ERROR]    Look at
'/home/roland/x-tools/i386-custom-linux-gnu/build.log' for more info on
this error.
[ERROR]  (elapsed: 11:09.87)

I have no idea why ../build-i486-build_pc-linux-gnu/libiberty/libiberty.a
would be needed at all. Wouldn't this only be needed for executables
that "run" on the build meachine?

> (In the spirit of crosstool-NG, a "native" compiler whould be able to install
>  in /, and be used as a replacement for the existing compiler. This raises a
>  few interesting points, such as headers and library search paths, run-time
>  paths, and so on...)

Hmm, the I do not understand what you wrote in overview.txt
> 1) build == host == target
>     This is a plain native toolchain, targetting the exact same machine as the
>     one it is built on, and running again on this exact same machine. You have
>     to build such a toolchain when you want to use an updated component, such
>     as a newer gcc for example.
>     crosstool-NG calls it "native".
> 
> 2) build == host != target
>     This is a classic cross-toolchain, which is expected to be run on the same
>     machine it is compiled on, and generate code to run on a second machine,
>     the target.
>     crosstool-NG calls it "cross".

Currently it looks to me as if host != target implies they must not be
the same machine, yes? (Hmm, altough you said:
> in the copmpiler land, a "machine" is not only referring
> to the hardware, but also to a few other parts

Do you have any suggestions what else I could try?

Thank you,
Roland

-- 
_________________________________________
  _  _  | Roland Schwarz
 |_)(_  | aka. speedsnail
 | \__) | mailto:roland.schwarz@chello.at
________| http://www.blackspace.at

--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]