Tiny Core Linux
Tiny Core Extensions => TCE Q&A Forum => Topic started by: dentonlt on February 01, 2014, 09:39:11 PM
-
(Perhaps this is better in the scripting or general sections, but I wasn't sure ... )
For PDFtk, I need gcj. So, I'm making a gcc-gcj extension for personal use. I did this on 32bit and it worked fine, but I'm beating my head against the wall trying to get 4.8.2 to compile on x86_64 for x86_64.
Current issue is the make chokes when it gets to libgomp. Make creates xgcc, and then libgomp says that xgcc doesn't work. That seems to be incorrect, though ... or at least I can get that new compiler to build a simple helloworld.c into a.out.
I've tried w/ and w/o distcc, rewriting my script, re-reading lotsa docs, changing CFLAGS/CXXFLAGS, adding -B to the 4.7.2 files, etc, etc. Advice welcome.
Build script + config log attached.
-
Are you using the compiletc extension in corepure64 to do this?
-
Yep. I've been using it to compile other things, and no major problems. I'll re-download it and deps to be sure.
Any other suggestions? I know you did the gcc ext, Juanito, so I appreciate it.
I'd even be happy with a 4.7.2 + gcj, in reality.
-
If you're compiling a gcc add-on, you probably need mpc-dev and cloog-dev, which are not normally loaded by compiletc
-
Yep, I have those installed during build. I'll re-download them, too. Thanks for mentioning.
Could this be because I'm on 5.2 / 3.8.13, and the headers are 3.8.10? I'm not compiling modules, so I didn't think it would matter. Maybe that was a poor assumption. I don't believe 3.8.13 headers are in the repository [yet?].
-
The 3.8.10 headers are the ones the tool chain was originally built with so they are the ones that should be used.
-
Ah - that makes sense.
Just to be complete, I've redownloaded every extension I need to use during the build. Now I'll sit and wait a few minutes during the build :p
-
No luck - same error as above.
New question: since mpl, binutils, etc. are all available in the repository, I have not included their source (as "optional"). Perhaps this was a poor decision?
I guess I'll try digging up all those and doing it altogether. I don't remember need to do that when I made the 32bit gcj, but maybe it's necessary here =\
[EDITED: stupid typo ... ]
-
I don't think that will change anything, I'd suggest using compiletc (i.e. the standard tc-5.x gcc) and something like this:
CFLAGS="-mtune=generic -Os -pipe" CXXFLAGS="-mtune=generic -Os -pipe" ./configure --prefix=/usr/local --libexecdir=/usr/local/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-c99 --enable-long-long --enable-clocale=gnu --enable-languages=c,c++,java --disable-multilib --disable-libstdcxx-pch --enable-cloog-backend=isl --with-system-zlib --enable-frame-pointer --disable-bootstrap --disable-cloog-version-check
-
I pulled the flags from the wiki, as normal, and then your gcc config from 4.7.2 using gcc -v ... so that looks like how I started :)
That's pretty much what I'm using now, but I struck a few things (-pipe, -Os, --enable-shared [default]) while trying to figure out what's wrong. I'll use exactly what you posted and try again.
Thanks again for the assistance with this ... It's really annoying me.
DLT
-
Still no good. At least I get the "can't run C compiled programs" error at a different point. End of make log below, and current build script attached.
I'll reboot, disable distcc, remove -jN, and try again. =\
configure: error: in `/home/tc/builder/gcc-4.8.2/gcc-4.7.2-objdir/x86_64-unknown-linux-gnu/libmudflap':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
configure: error: in `/home/tc/builder/gcc-4.8.2/gcc-4.7.2-objdir/x86_64-unknown-linux-gnu/libffi':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[1]: *** [configure-target-libmudflap] Error 1
make[1]: *** Waiting for unfinished jobs....
configure: error: in `/home/tc/builder/gcc-4.8.2/gcc-4.7.2-objdir/x86_64-unknown-linux-gnu/libgomp':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
configure: error: in `/home/tc/builder/gcc-4.8.2/gcc-4.7.2-objdir/x86_64-unknown-linux-gnu/libssp':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[1]: *** [configure-target-libffi] Error 1
configure: error: in `/home/tc/builder/gcc-4.8.2/gcc-4.7.2-objdir/x86_64-unknown-linux-gnu/zlib':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[1]: *** [configure-target-libgomp] Error 1
configure: error: in `/home/tc/builder/gcc-4.8.2/gcc-4.7.2-objdir/x86_64-unknown-linux-gnu/libquadmath':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[1]: *** [configure-target-libssp] Error 1
make[1]: *** [configure-target-zlib] Error 1
make[1]: *** [configure-target-libquadmath] Error 1
make: *** [all] Error 2
-
Failed on base norestore. :-[
Again, the same error. Gets to libgomp, and then crash out with "cannot run C compiled programs."
I'll keep looking for other options/variables.
-
Could be the xgcc script prefers bash, or gnu utils vs busybox?
-
Thanks, curaga, but already using bash + gnu utils (gawk in particular is required). =\
Any other loose ends that you can think of that might need non-busybox???
-
Hm, well some apps want the glibc_apps extension, it's not a compiletc dep.
edit: Of course you could use your 32-bit system to build a static pdftk binary? That would then run fine on your 64-bit box too.
-
Ah - building on 32 isn't a half bad idea, now that you mention it. I think I've since killed that gcj build, though =( I don't have the static libs that I need anymore. The .so libs are in the pdftk extension, but then I'd have to learn how to make those static ... [gulp].
I'm not sure I've been using glibc_apps - I'll try that one next. It's 11pm where I am though, so it will have to wait until tomorrow afternoon.
Thanks again for the assistance, all. I'll keep you posted.
[EDIT: ok, that was quick. I'm already using building with glibc_apps. I'll keep thinking. #$*! ]
-
I found the problem - in fact there were two...
The ppl-dev extension's *.la files were messed up, although I don't think this has anything to do with the problem (corrected version posted)
One of the header files (gcc/config/i386/linux64.h) in the gcc-4.7.2 source believes ld-linux* is in /lib64 instead of /lib - correcting this fixes the problem and gcc-java compiles without further issues, except that it installs the libs in /usr/local/lib64 even if you tell it not to. Not a big deal to move the dynamic libs, but the *.la files will need adjusting.
-
Hm, you didn't use the pure64 patches? Or symlink lib64 to lib?
-
The specs file normally takes care of the linking and I'd rather avoid the symlink if possible - this is the first time I saw this kind of problem.
-
First chance I've had to check the forum - in short, awesome. Thanks so much for digging on it, Juanito. I'll re-try the build myself later today.
Since it's obscure, do you mind explaining how you tracked down the bug? I was at a loss since the conftest.c file is immediately removed by make. =/
-
I'd seen something similar when building the toolchain for tc-5.x, I though the gcc specs file took care of this, but apparently not for compiling gcc itself.
-
Just about to start a build attempt. I downloaded the new ppl-dev, but tce-load gives me an md5sum error. Probably just needs a new .md5.txt, yes? Repeated downloads give a consistent:
cb9a872163f35650914518c2b3815eef /tce/ppl-dev.tcz
I'll take it as stable.
DLT
-
Success! For reference, build script attached (requires bash).
Thanks again, gentlemen - really very much appreciated.