| 01:09.35 | *** join/#uclibc TheMasterMind1 (~aman@h-68-166-69-184.MCLNVA23.covad.net) |
| 04:33.56 | *** join/#uclibc mutex (~mutex@h-68-164-243-10.SNVACAID.covad.net) |
| 07:30.07 | mutex | andersee: i don't understand the reason for the glibc include and start files patching |
| 07:30.54 | mutex | the toolchain builder does this before it builds uclibc, so ... is it just for making sure glibc doesn't get in.. not that uclibc gets in |
| 07:42.54 | andersee | mutex: glibc? |
| 07:43.17 | andersee | mutex: Could you be a bit more specific? |
| 07:43.31 | mutex | well |
| 07:43.55 | mutex | there is a set of perl, search and replace lines in the uclibc_toolchain.mk file |
| 07:44.00 | mutex | in the buildroot tarball |
| 07:44.14 | andersee | mutex: yes |
| 07:44.30 | mutex | i don't understand why you use some of the ones you use |
| 07:44.43 | mutex | specifically for gcc |
| 07:44.46 | andersee | mutex: ok. |
| 07:44.50 | andersee | mutex: Look here: |
| 07:44.54 | andersee | http://uclibc.org/cgi-bin/cvsweb/buildroot/make/uclibc_toolchain.mk?annotate=1.45 |
| 07:45.04 | andersee | And specify line numbers... |
| 07:45.12 | mutex | good call |
| 07:45.36 | mutex | 224-237 |
| 07:47.45 | andersee | If you look in gcc-3.2.3/gcc/gcc.c for standard_startfile_prefix_1 and standard_startfile_prefix_2 you will see it attempts to hard code paths for its start files. |
| 07:47.56 | mutex | indeed i see this |
| 07:49.48 | andersee | Problem is, for buildroot at least, we don't want to be looking at /lib and /usr/lib -- we want gcc to look under the buildroot staging area and nowhere else |
| 07:50.06 | mutex | but at this point there is no headers in there |
| 07:51.17 | mutex | at the stage this gcc compile takes place, binutils has been compiled and nothing else... |
| 07:51.18 | andersee | Sure. for a stage 1 compiler that is fine. But we will be using the resulting compiler soon and we want it to behave itself. |
| 07:51.30 | mutex | aaahh, ok |
| 07:51.34 | mutex | hrm |
| 07:52.23 | mutex | that's strange |
| 07:52.25 | andersee | this particular hack has a much more important effect for the stage 2 compiler. But I put it here since it doesn't hurt anything |
| 07:52.37 | mutex | i can see how it would cause trouble |
| 07:52.48 | mutex | but my question is, why is that not a autoconf parameter |
| 07:52.57 | mutex | i suppose it is more rhetorical than anything |
| 07:53.26 | andersee | mutex: because the gcc folk didn't add it, and I have not attempted to supply them with a patch to do things properly |
| 07:53.51 | mutex | i see |
| 07:53.55 | mutex | unfortunate |
| 07:54.14 | andersee | mutex: In an ideal world, I would add a --with-uclibc type configure option that would automagically enable all the needed magic |
| 07:54.21 | andersee | But I have not done that |
| 07:54.31 | mutex | that would be very nice |
| 07:55.49 | andersee | mutex: agreed it would be nice. But I am afraid that will probably be a project for someone else. I have thus far not had the interest/energy to make such a patch. |
| 07:56.20 | mutex | well i wasn't implying you should do it, but an interesting thought |
| 07:57.00 | mutex | andersee: how many people actively hack uclibc ? |
| 07:57.56 | andersee | mutex: I've received patches from a number of people. But primarily, there is just me and Manuel that have done the _vast_ majority of the work |
| 08:00.39 | mutex | and bug fixing i assume as well |
| 08:01.15 | andersee | But of course... bug fixing constitutes the vast majority of the work. ;-) |
| 08:01.23 | mutex | heh |
| 16:13.34 | *** join/#uclibc randey (~randey@202.174.134.4) |
| 18:20.15 | *** join/#uclibc andersee (~andersen@codepoet.org) |
| 18:42.22 | mut3x | is there any way that i can tell if I have properly built gcc for use with uclibc, rather than glibc ? other than attempting to compile something |
| 18:45.59 | andersee | mut3x: I used 'gcc -v' a lot to watch exactly what paths and such are being used... |
| 18:46.29 | andersee | mut3x: I probably rebuilt gcc at least a hundred times before I got things right |
| 18:46.44 | mut3x | heh, that's why i figured you'd be a good person to ask |
| 18:46.59 | mut3x | though hopefully i don't become the annoying newbie |
| 18:48.19 | andersee | nah |
| 18:48.42 | andersee | Just make liberal use of 'gcc -v' and watch what it is doing |
| 19:04.33 | *** join/#uclibc randey (~randey@pptp3.speedcast.com) |
| 20:16.07 | mut3x | ok, so... |
| 20:16.27 | mut3x | the dynamic linker replacement script lines |
| 20:17.05 | mut3x | seem to keep gcc from compiling because: "./gengenrtl -h > tmp-genrtl.h" this line failes, since gengenrtl is never compiled |
| 20:17.13 | mut3x | any clue about what this executable does ? |
| 20:24.33 | andersee | Hmmm |
| 20:24.47 | andersee | Which gcc target is it run from. |
| 20:25.12 | mut3x | target as in ... '--target' or what version of gcc ? |
| 20:25.21 | andersee | It appears it is built and executed. Perhaps being built using the target C lib... |
| 20:25.44 | mut3x | no it isn't being built and executed |
| 20:25.47 | mut3x | /bin/sh: line 1: ./gengenrtl: No such file or directory |
| 20:25.52 | mut3x | is the actual error line |
| 20:26.27 | mut3x | and i was hoping to avoid building using the target C lib, since this is a stage1 compiler at this point |
| 20:26.57 | andersee | [andersen@dillweed toolchain_build_i386]$ find -name gengenrtl |
| 20:26.57 | andersee | ./gcc-initial/gcc/gengenrtl |
| 20:26.57 | andersee | ./gcc-final/gcc/gengenrtl |
| 20:26.57 | andersee | [andersen@dillweed toolchain_build_i386]$ ldd ./gcc-initial/gcc/gengenrtl |
| 20:26.57 | andersee | <PROTECTED> |
| 20:26.58 | andersee | <PROTECTED> |
| 20:27.39 | andersee | Looks like it is a binary intended for the build system, not the target. I betcha you compiled it for the target. Or tried to... |
| 20:27.56 | mut3x | welll |
| 20:27.57 | mut3x | hrm |
| 20:28.12 | mut3x | the thing that does it is the -dynamic-loader replacement line, i've narrowed it down to that |
| 20:28.15 | mut3x | which i find odd |
| 20:29.58 | andersee | But the -dynamic-loader replacement line should have _ZERO_ effect on a host binary. Which is why I think you are using the wrong CC to build /gcc-3.2.3/gcc/gengenrtl.c |
| 20:30.46 | mut3x | CC = cross compiler ? |
| 20:30.48 | andersee | If you look at the generated Makefile... |
| 20:30.55 | andersee | CC = C compiler |
| 20:30.58 | mut3x | ah ok |
| 20:30.59 | andersee | gengenrtl$(build_exeext) : gengenrtl.o $(HOST_LIBDEPS) |
| 20:30.59 | andersee | <PROTECTED> |
| 20:30.59 | andersee | <PROTECTED> |
| 20:30.59 | andersee | gengenrtl.o : gengenrtl.c $(RTL_BASE_H) $(HCONFIG_H) $(SYSTEM_H) real.h |
| 20:31.00 | andersee | <PROTECTED> |
| 20:31.18 | andersee | It is clearly using the HOST_CC... Not for the target. |
| 20:31.28 | mut3x | hmm well i only have one CC on my machine |
| 20:31.42 | mut3x | 3.2.2 |
| 20:32.29 | andersee | If the -dynamic-loader replacement line is causing this grief, the host binary building stuff is infected with stuff for the target. |
| 20:33.17 | mut3x | ah, the stuff i was discussing with you last night |
| 20:33.36 | mut3x | the target lib #defines |
| 20:35.58 | mut3x | ah i missed a section of your include header rewriting |
| 20:37.16 | mut3x | hrm... |
| 20:37.42 | mut3x | ok, but if i'm rewriting these things to NOT include glibc headers, and i point them to my new 'staging directory' and there _are_ no libc headers of any kind |
| 20:37.50 | mut3x | will it still compile |
| 21:06.40 | andersee | mut3x: I think you are missing something. |
| 21:07.14 | mut3x | hmm missing as forgetting ? or missing as in I am not 'getting it' ;-) ? |
| 21:08.09 | andersee | mut3x: The HOST, or build, system is generally running glibc. During the gcc build process, some binaries are compiled to be run on the HOST system. |
| 21:08.55 | mut3x | hmmm that is how things are supposed to work then ? |
| 21:09.22 | andersee | mut3x: The gcc build process cannot and should not try to compile _everything_ for the TARGET system (i.e. compile everything vs uClibc). |
| 21:09.38 | mut3x | hmm ok |
| 21:10.04 | andersee | mut3x: so lets step back a little bit. |
| 21:10.12 | mut3x | ok, lets |
| 21:10.15 | andersee | mut3x: What exactly are you trying to produce? |
| 21:10.33 | mut3x | well |
| 21:10.45 | *** join/#uclibc zwelch (~kumquat@fluffy.superlucidity.net) |
| 21:10.54 | mut3x | gcc stage 1, at a point where i can compile uclibc |
| 21:11.01 | andersee | ok |
| 21:11.04 | mut3x | to (eventually) produce a uclibc toolchain |
| 21:11.40 | andersee | And for a stage 1 compiler, gcc will be linked vs the host system's C library (typically glibc) |
| 21:11.48 | mut3x | alright |
| 21:11.56 | andersee | ok |
| 21:12.38 | andersee | mut3x: And you are working from the make/uclibc_toolchain.mk example in buildroot? |
| 21:12.49 | *** join/#uclibc TheMasterMind1 (~aman@h-68-166-68-149.MCLNVA23.covad.net) |
| 21:12.53 | mut3x | exactly what i'm refrencing |
| 21:13.01 | mut3x | *that is exactly |
| 21:13.11 | zwelch | andersee: http://wiki.dev.gentoo.org/gentoo/moin.cgi/GentooEmbedded_2fMewClibc |
| 21:13.24 | zwelch | have you been pointed at this yet? |
| 21:13.29 | andersee | Tried this http://uclibc.org/cgi-bin/cvsweb/toolchain/ |
| 21:13.34 | andersee | ? |
| 21:14.02 | andersee | If you just want a toolchain that is a more direct example. |
| 21:14.02 | mut3x | what do you mean 'tried' ? |
| 21:14.09 | mut3x | ah |
| 21:14.10 | mut3x | ok |
| 21:14.14 | mut3x | i didn't see the difference |
| 21:14.37 | andersee | Same basic idea. But produces just a toolchain, nothing else |
| 21:14.43 | andersee | zwelch: looking |
| 21:14.45 | mut3x | that may be better for me |
| 21:14.46 | zwelch | mut3x: i was able to adapt the patches for uClibc into my ebuilds from that Makefile |
| 21:15.04 | zwelch | mut3x: i thought that's what you were working off of :/ |
| 21:15.19 | mut3x | zwelch: erp ? i'm confused.. what are you talking about |
| 21:16.28 | zwelch | mut3x: the Makefile found under that cvsweb URL has all the patches you need to build a uClibc toolchain |
| 21:16.38 | mut3x | ah |
| 21:16.41 | mut3x | well then ;-) |
| 21:16.41 | zwelch | and they are "fairly easily" adapted to the ebuilds |
| 21:17.01 | zwelch | mut3x: sorry, as i said, i thought that's what you were working off of |
| 21:17.14 | mut3x | no, i was working off the buildroot toolchain makefile |
| 21:18.14 | mut3x | this looks very similar to what i was using |
| 21:18.46 | mut3x | and i don't see much difference... although i shall continue ;-) |
| 21:20.05 | mut3x | although ihave to admit, i did not apply these patches |
| 21:22.11 | zwelch | andersee: i just made a few minor updates to that page that should make it a little nicer to look at and navigate between the rest of the site. In essense, the uClibc page represents one small part of the overall Gentoo Embedded project I am currently leading. |
| 21:23.57 | zwelch | in the not too distant future, I plan to extend our current support for "one-step" cross-compiler to support different binutils, libc, and cc components; in effect, allowing the user to produce uClibc-based cross-compiling toolchian that installs in parallel with existing glibc-based toolchains |
| 21:25.00 | andersee | zwelch: i.e. sortof like the toolchains I make available on uClibc.org. ;-) |
| 21:25.14 | mut3x | andersee: yeah, but package management included ;-) |
| 21:25.21 | andersee | :) |
| 21:25.26 | zwelch | andersee: right :) |
| 21:26.36 | zwelch | andersee: truly the "only" advatage will we have is the ability to then transparently use these cross-compilers with the package manager |
| 21:28.50 | andersee | Sounds pretty cool |
| 21:30.16 | andersee | One of the reasons I made my toolchains and buildroot system (other than the fact that nobody else was doing it) was so I could use it to bootstrap a debian base system using uClibc |
| 21:30.50 | andersee | I still havn't finished doing that.... I got distracted a few months ago, and havn't gotten back to it. |
| 21:32.31 | mut3x | well the other cool thing |
| 21:32.47 | mut3x | is then you can use emerge to produce a set of packages to put in the system |
| 21:33.01 | mut3x | and you get the flexibility of emerge as a build enviornment |
| 21:33.14 | zwelch | andersee: that's essentially what the package management integration will give us |
| 21:33.49 | andersee | Essentially the same goal as I had |
| 21:33.55 | zwelch | CBUILD=i686-pc-linux-gnu CHOST=armv4l-unknown-linux-gnu ROOT=/some/place/safe emerge system |
| 21:34.06 | zwelch | and it'll build your arm system in that safe place |
| 21:34.19 | andersee | zwelch: How do you handle cross-configuration? |
| 21:34.29 | zwelch | andersee: ummm... carefully |
| 21:34.33 | mut3x | heh heh |
| 21:34.34 | zwelch | we're still solving the details |
| 21:34.38 | mut3x | 'carefully' |
| 21:34.44 | andersee | zwelch: i.e. when ./configure for openssh tries to run arm tests on the host x86 build system? |
| 21:34.48 | mut3x | it 'carefully' unmerged my entire system a couple weeks ago ;-) |
| 21:34.52 | zwelch | but we do have a master plan written on the back of a napkin somewhere |
| 21:35.06 | zwelch | andersee: we have a solution ;) |
| 21:35.26 | zwelch | mut3x: yah, well, i won't try to claim we have it all today |
| 21:35.47 | mut3x | zwelch: i know, i' |
| 21:35.53 | zwelch | andersee: a key reason i'm going for cross-compilers is for distcc support |
| 21:35.54 | mut3x | i'm just giving you a hard time |
| 21:36.16 | zwelch | andersee: this way, a slow pathetic host can run the configure jobs and then farm them out over distcc |
| 21:36.29 | zwelch | s/them/the real compiling/ |
| 21:36.46 | zwelch | and *that* does work great today :) |
| 21:37.35 | andersee | hehe |
| 21:38.44 | mut3x | zwelch: finally got that line fixed |
| 21:39.30 | mut3x | yay for me |
| 21:42.46 | mut3x | zwelch: erik and i had a discussion last night where he explained that unfortunately it looks like these evil little hacks are necessary until gcc has a --with-uclibc in configure |
| 21:58.34 | zwelch | excellent, i am glad to hear that gcc will be made more "open" to other libcs |
| 22:01.11 | mut3x | well 'open' as long as somebody produces this patch ;-) |
| 22:01.22 | mut3x | to provide the functionality mentioned |
| 22:01.39 | mut3x | hrm |
| 23:10.54 | mut3x | andersee: well my previous problem with gengentrl was due to a typo.. |
| 23:12.49 | andersee | mut3x: oh? |
| 23:12.58 | andersee | Wrong CC? |
| 23:13.11 | mut3x | sed -e 's/-dynamic-linker.*\.so[\.0-9]*/-dynamic-linker \/lib\/ld-uClibc.s\o.0/g' -i $file |
| 23:13.19 | mut3x | should be: sed -e 's/-dynamic-linker.*\.so[\.0-9]*}/-dynamic-linker \/lib\/ld-uClibc.s\o.0}/g' -i $file |
| 23:17.09 | mut3x | silly, but seems to be the cause |
| 23:17.51 | andersee | little bitty typos like that can cause big 'ol problems |
| 23:18.01 | mut3x | ack! |
| 23:18.12 | mut3x | blew up again |
| 23:18.42 | andersee | paste in the error? |
| 23:18.58 | mut3x | stage1/xgcc -Bstage1/ -B/usr/i686-pc-linux-gnu/bin/ -DIN_GCC -pipe -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -DGENERATOR_FILE -o genpreds \ |
| 23:18.58 | mut3x | <PROTECTED> |
| 23:18.58 | mut3x | ./gengenrtl -h > tmp-genrtl.h |
| 23:18.58 | mut3x | /bin/sh: line 1: ./gengenrtl: No such file or directory |
| 23:18.59 | mut3x | make[2]: *** [s-genrtl] Error 127 |
| 23:19.01 | mut3x | make[2]: *** Waiting for unfinished jobs.... |
| 23:19.03 | mut3x | make[2]: Leaving directory `/var/tmp/portage/gcc-3.2.2-r7/work/build/gcc' |
| 23:19.05 | mut3x | make[1]: *** [stage2_build] Error 2 |
| 23:19.07 | mut3x | make[1]: Leaving directory `/var/tmp/portage/gcc-3.2.2-r7/work/build/gcc' |
| 23:19.09 | mut3x | make: *** [bootstrap-lean] Error 2 |
| 23:20.44 | andersee | mut3x: do a 'readelf -a gengenrtl | grep NEEDED' |
| 23:21.20 | andersee | Obviously inserting the proper gengenrtl path |
| 23:21.24 | mut3x | heh |
| 23:21.35 | mut3x | not obvious for me :-( |
| 23:22.06 | mut3x | but the executable isn't created |
| 23:22.25 | andersee | are you _sure_ |
| 23:23.08 | mut3x | ok, i shall go dig for it |
| 23:23.36 | mut3x | hmmm |
| 23:23.37 | andersee | i.e. the same think I suggested was wrong, oh, several hours ago |
| 23:23.40 | mut3x | well, your right as usual |
| 23:23.46 | mut3x | <PROTECTED> |
| 23:24.03 | andersee | Try looking for INTERP now |
| 23:24.24 | mut3x | <PROTECTED> |
| 23:24.32 | mut3x | that look familiar |
| 23:24.39 | andersee | Add a -A1 to the grep. :) |
| 23:25.36 | andersee | i.e. 'readelf -a gengenrtl | grep -A1 INTERP' |
| 23:25.40 | mut3x | right |
| 23:25.45 | mut3x | brb, gotta run an errand :-/ |
| 23:25.58 | andersee | later |
| 23:30.22 | mut3x | <PROTECTED> |
| 23:30.22 | mut3x | <PROTECTED> |
| 23:30.48 | mut3x | so it is against ld-uClibc.so.0 |
| 23:30.59 | mut3x | and it needs to be linked against the system libc, iirc |
| 23:31.44 | andersee | Somehow, the shared lib loader hack is inadvertantly causing these binaries to use the uClibc shared lib loader. |
| 23:32.07 | andersee | The funny thing is, if you copied ld-uClibc.so.0 into /lib it would probably work. |
| 23:32.14 | mut3x | right |
| 23:32.27 | andersee | And may very well be why I havn't seen that before. |
| 23:32.40 | mut3x | interesting |
| 23:32.40 | andersee | I assume you were copying my hack exactly? |
| 23:32.45 | mut3x | yup |
| 23:32.50 | mut3x | well |
| 23:32.55 | mut3x | translated to sed ;-) |
| 23:32.57 | mut3x | but the same |
| 23:33.18 | andersee | mut3x: you get a gold star for finding a bug in my code. :-) |
| 23:33.26 | mut3x | woohoo |
| 23:33.37 | mut3x | well I could easily exempt the file |
| 23:36.06 | mut3x | i guess we will find out if there are other instances of this ... |
| 23:46.39 | mut3x | hmm |
| 23:49.07 | mut3x | this version doesn't want to be linked against uClibcl.so.0 though, or.. doesn't need to be |
| 23:49.18 | mut3x | it just needs to produce uClibc.so.0, correct ? |
| 23:49.33 | mut3x | then the subsequent compilation(full gcc) should be linked against uclibc |
| 23:54.17 | andersee | The gengenrtl app is a host app. It does not need or want uClibc |
| 23:54.50 | mut3x | clearly |
| 23:55.03 | mut3x | but in the stage1 compile, does _anything_ need uClibc |
| 23:55.24 | andersee | nope |
| 23:55.32 | mut3x | i see |
| 23:55.36 | mut3x | well then |
| 23:55.41 | mut3x | that makes my job easier |