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] |
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] |