| 00:05.19 | CIA-2 | 03vda * r24024 10busybox/ (include/usage.h networking/arp.c): (log message trimmed) |
| 00:05.19 | CIA-2 | arp: stop using globals |
| 00:05.19 | CIA-2 | function old new delta |
| 00:10.53 | *** join/#uclibc hiyuh (n=hiyuh@ZQ062141.ppp.dion.ne.jp) |
| 00:29.00 | *** join/#uclibc wrobbie (n=rob@203.117.215.163) |
| 03:27.51 | *** join/#uclibc tazmania1 (n=sandp@7.47.49.60.kmr01-home.tm.net.my) |
| 03:28.25 | *** join/#uclibc tsukasa` (n=tsukasa@unaffiliated/tsukasa) |
| 03:28.32 | tazmania1 | when selecting ash shell in busybox, should I select Builtin echo, printf, and test? |
| 03:31.20 | landley | Might as well. |
| 03:35.51 | tazmania1 | what are the differences between the builtin and the busybox's? |
| 03:36.10 | tazmania1 | because I have also selected those commands in busybox |
| 03:36.50 | landley | It doesn't go out and check the filesystem for the build in versions. |
| 03:37.12 | landley | In theory with the new nofork stuff, a lot of commands can be run without looking at the filesystem and execing something new. |
| 03:37.29 | landley | In practice, there's a lot of legacy stuff from ash's history as a separate program that got bolted onto busybox. |
| 03:37.46 | landley | Still being cleaned up, last I checked. But I'm about a year out of date, some of the cleanup may already have happened... |
| 03:38.30 | tazmania1 | OK. Thanks for the highlight ;) |
| 03:47.25 | landley | Has anybody gotten dynamically linked uClibc sparc to work? |
| 03:47.25 | landley | The dynamic linker is insisting a file isn't an elf executable when "file" disagrees. |
| 03:47.38 | landley | <PROTECTED> |
| 03:47.38 | landley | <PROTECTED> |
| 03:47.50 | landley | file libdl-0.9.30.so |
| 03:47.50 | landley | libdl |
| 03:48.02 | swishy | :\ |
| 03:48.04 | landley | Ahem: second attempt at pasting that. |
| 03:48.07 | landley | file libdl-0.9.30.so |
| 03:48.08 | landley | libdl-0.9.30.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped |
| 03:48.20 | landley | If I set init to a statically linked hello world file, it prints out "Hello world!" just fine (before panicing because PID 1 exited, but that's to be expected). |
| 03:48.52 | landley | So it's clearly the dynamic linker and not anything _obvious_ in my toolchain, qemu, or libuClibc.so |
| 03:49.24 | landley | Please tell me this is a known bug with a known fix so I don't have to spend half of tomorrow sticking printfs in the dynamic linker. |
| 03:56.40 | solar | you can't add printf() to the linker btw |
| 03:57.13 | solar | use it's gotta use it's internal debug printf work alike functions |
| 03:58.10 | landley | No it doesn't, it can write(2,"wombat\n"), I just _say_ printf. :) |
| 03:58.41 | landley | (And I think you can use sprintf, I forget. I've debugged the dynamic linker before, but it was a year ago...) |
| 03:59.15 | landley | The reason you can't use printf() is because stdio hasn't been initialized yet... |
| 03:59.20 | solar | anyway pretty sure it's just the crt*.S files needing an update |
| 03:59.20 | landley | So no FILE * operations. |
| 04:00.01 | landley | solar: how do the crt*.S files cause it to mis-identify share libraries at runtime, but not have a problem linking static libraries at compile time? |
| 04:00.30 | landley | (It's quite possible that's the case, I just don't understand how.) |
| 04:00.42 | landley | But not understanding is my normal starting point, so... |
| 04:01.15 | solar | gcc -v and watch which files it uses |
| 04:01.36 | solar | it will be like crtn vs crts or so. |
| 04:02.22 | landley | watch which files _what_ uses. The dynamic linker, or the dynamic version of hello world? |
| 04:02.47 | solar | the linker line. |
| 04:02.56 | solar | sec I'll give example |
| 04:04.10 | solar | collect2 somewhere. sec |
| 04:05.13 | landley | <PROTECTED> |
| 04:05.13 | landley | build/cross-compiler-sparc/bin/../gcc/lib/crtbegin.o build/cross-compiler-sparc/bin/../lib/crt1.o /tmp/ccEMMTQ9.o -lgcc -lc -lgcc build/cross-compiler-sparc/bin/../gcc/lib/crtend.o build/cross-compiler-sparc/bin/../lib/crtn.o |
| 04:05.40 | solar | static linking should use it looks like crtbeginT.o vs crtbegin.o |
| 04:05.44 | landley | A dynamically linked "hello world" has the same problem. |
| 04:05.47 | landley | That was dynamic. |
| 04:05.51 | landley | Static would be: |
| 04:06.07 | landley | <PROTECTED> |
| 04:06.07 | landley | build/cross-compiler-sparc/bin/../lib/crt1.o /tmp/cc489pEB.o -lgcc -lc -lgcc build/cross-compiler-sparc/bin/../gcc/lib/crtend.o build/cross-compiler-sparc/bin/../lib/crtn.o |
| 04:06.52 | solar | does build/cross-compiler-sparc/bin/../gcc/lib/crtbeginT.o exist? |
| 04:07.30 | solar | actually that is odd. |
| 04:07.36 | landley | -rw-r--r-- 1 landley landley 2284 2008-11-12 16:41 build/cross-compiler-sparc/gcc/lib/crtbeginT.o |
| 04:08.08 | landley | I have to pack up in about 10 minutes, restaurant closing. |
| 04:08.30 | solar | static linking work, but both are using the same crt file and in an almost backwords order for the one that works |
| 04:08.49 | landley | shrugs. |
| 04:08.59 | landley | Might be the build wrapper. It's using the same order on all targets. |
| 04:09.08 | solar | anyway. sparc.. Have fun with that one |
| 04:09.18 | landley | I have to head home, back online in half an hour or so. |
| 04:09.24 | landley | Could you email me the "order that works"? :) |
| 04:09.27 | solar | I think I've seen about 2 people show interest in it ever. |
| 04:09.33 | landley | Yeah, I'm one of them. |
| 04:09.36 | solar | haha |
| 04:09.39 | landley | Completist: qemu supports it, so should I. |
| 04:09.51 | landley | I'm trying to get _alpha_ to work. |
| 04:10.02 | landley | Or at least when they get a board. |
| 04:10.12 | landley | (I care about qemu-system-$ARCH, not so much qemu-$ARCH.) |
| 04:10.15 | landley | Gotta run... |
| 04:11.07 | solar | cya |
| 04:44.07 | *** join/#uclibc landley (n=landley@cpe-70-116-30-223.austin.res.rr.com) |
| 04:45.27 | landley | solar: I don't think it's the crt*.o files. |
| 04:52.34 | solar | thinks that is where it all starts |
| 04:53.00 | landley | I don't think the failure would be at that point. |
| 04:53.05 | solar | but I'm not debugging it. You are. It very well could be a bug in qemu with dyn linking? |
| 04:53.11 | landley | Either it would'nt get to the dynamic linker at all, or it would hit after the dynamic linker had done its thing. |
| 04:53.29 | landley | The dynamic linker is figuring out _which_ libraries to import. It's just failing some kind of sanity test looking at their headers. |
| 04:53.44 | landley | I'm poking at it, but first I'm trying to figure out why uClibc keeps re-extracting itself. |
| 05:04.50 | landley | Oh dear. |
| 05:05.10 | landley | Blizzard sent me a 10 day free trial of Burning Crusade, reactivating my World of Warcraft account. |
| 05:05.13 | landley | is doomed. |
| 05:08.07 | landley | I'm having enough trouble with all the episodes of "bleach" on hulu... |
| 05:08.31 | landley | (Episode 31, people yell at each other at length, and posture, and there's more swordplay!) |
| 05:42.50 | *** join/#uclibc _lifeless (n=lifeless@90.151.35.81) |
| 06:20.12 | *** join/#uclibc _lifeless (n=lifeless@90.151.35.81) |
| 06:28.59 | *** join/#uclibc nwmcsween (n=nwmcswee@69.176.163.205) |
| 07:11.09 | landley | The number of warnings uClibc for sparc produces is kind of impressive. |
| 07:11.58 | ncopa | anyone tried to compile gcc-4.3.2 with uclibc, native? |
| 07:15.12 | ncopa | aha |
| 07:15.27 | ncopa | libgomp configure script fails |
| 07:15.40 | ncopa | du to the test program uses -lpthread |
| 07:16.10 | landley | -lpthread should work, assuming you configured threads? |
| 07:16.35 | ncopa | seems like i have to fix the -lpthread business to be able to compile gcc |
| 07:16.35 | ncopa | it does not |
| 07:16.40 | ncopa | just linking pthread makes programs to segfault |
| 07:17.05 | ncopa | i tried linuthreads.old |
| 07:17.07 | ncopa | and new |
| 07:17.10 | ncopa | same on both |
| 07:17.12 | landley | which target? |
| 07:17.15 | ncopa | x86 |
| 07:17.23 | landley | That's working for me... |
| 07:17.34 | landley | Although "linking with gcc 4.3.2" isn't something I've tried... |
| 07:18.11 | ncopa | no |
| 07:18.21 | ncopa | its gcc-3.4.6 |
| 07:18.23 | ncopa | actually |
| 07:18.39 | ncopa | its both xgcc 4.3.2 and gcc 3.4.6 |
| 07:18.59 | ncopa | landley: do you have UCLIBC_DYNAMIC_ATEXIT=y |
| 07:18.59 | ncopa | COMPAT_ATEXIT=y |
| 07:20.02 | landley | UCLIBC_DYNAMIC_ATEXIT=y |
| 07:20.10 | landley | LINUXTHREADS_OLD=y |
| 07:20.20 | landley | No COMPAT_ATEXIT. |
| 07:26.19 | ncopa | landly, could i have a copy of your config? |
| 07:35.01 | landley | ncopa: sure. |
| 07:36.03 | landley | wget http://landley.net/config-uClibc |
| 07:37.58 | ncopa | thanks |
| 07:39.48 | landley | Does anybody here do sparc? |
| 07:40.31 | landley | My .config is set to sparc v8, but my compiler is not defining the "defined(__sparc_v8__)" that uClibc's dl-sysdep.h is looking for. |
| 07:41.13 | landley | Thus my compiler is building ELF executalbes where e_machine is EM_SPARC32PLUS, but the uClibc dynamic loader is only accepting EM_SPARC. |
| 07:41.24 | landley | Shouldn't this be MAGIC1 and MAGIC2 maybe? |
| 08:02.28 | *** join/#uclibc wrobbie (n=rob@203.117.215.163) |
| 08:21.27 | ncopa | interesting, with DODEBUG -pthreads seems to work |
| 08:24.47 | *** join/#uclibc hw (n=hw@p578b3905.dip0.t-ipconnect.de) |
| 08:33.07 | landley | No idea. |
| 08:33.26 | landley | Fixing the sparc MAGIC2 bug got me back to the old "any attempt to read from stdin hangs" bug from 0.9.29. Wheee... |
| 08:47.14 | mjf_ | morning |
| 09:11.35 | landley | Morning. |
| 09:11.38 | landley | Sparc is evil. |
| 09:12.12 | mjf_ | heh |
| 09:58.19 | ncopa | got some help from timo teras with the -lpthread business |
| 09:58.28 | ncopa | it is a gcc bug |
| 09:58.33 | ncopa | definitively |
| 09:59.20 | landley | Um... good? I think? |
| 10:00.10 | ncopa | i'm testing |
| 10:00.22 | ncopa | i can workaround it with -fno-omit-framepointer |
| 10:00.32 | ncopa | looking at psm's stuff, he did the same |
| 10:04.10 | landley | Cool. |
| 10:05.08 | ncopa | yup |
| 10:05.19 | ncopa | no doubt |
| 10:05.35 | ncopa | with -fno-omit-frame-pointer it works |
| 10:07.44 | blindvt` | ncopa, what's the difference? |
| 10:08.17 | blindvt` | is the unwinder confused or something else? |
| 10:09.52 | ncopa | <tteras> the disassembly looks exactly like the gcc generated code to access framepointer which is not there |
| 10:09.52 | ncopa | <PROTECTED> |
| 10:09.52 | ncopa | <PROTECTED> |
| 10:09.52 | ncopa | <PROTECTED> |
| 10:09.52 | ncopa | <PROTECTED> |
| 10:10.25 | ncopa | as i understand it, its a bug in gcc |
| 10:10.45 | ncopa | generates code without framepointer, then tries to access it anyway |
| 10:11.40 | ncopa | i guess gentoo embedded/hardened would be interesting in this patch |
| 10:12.08 | *** part/#uclibc tazmania1 (n=sandp@7.47.49.60.kmr01-home.tm.net.my) |
| 10:12.34 | ncopa | woot |
| 10:12.39 | ncopa | now my gcc compiles |
| 10:31.07 | *** join/#uclibc wiking__ (n=wiking@91.83.10.176.pool.invitel.hu) |
| 10:37.15 | *** join/#uclibc vinilios (n=k88@adsl16-94.ath.forthnet.gr) |
| 10:38.54 | CIA-2 | 03aldot * r24025 10uClibc/libc/inet/ifaddrs.c: - silence shadow warning |
| 10:50.22 | *** join/#uclibc _lifeless (n=lifeless@90.151.35.81) |
| 11:44.51 | *** join/#uclibc __lifeless (n=lifeless@90.151.35.81) |
| 11:55.39 | *** join/#uclibc Xires (n=Xires@71-11-230-70.dhcp.ftwo.tx.charter.com) |
| 11:55.39 | *** join/#uclibc mtr (n=michael@v29762.1blu.de) [NETSPLIT VICTIM] |
| 12:23.48 | CIA-2 | 03vda * r24026 10busybox/ (libbb/pw_encrypt_sha.c loginutils/cryptpw.c): |
| 12:23.48 | CIA-2 | libbb: remove glibc-style bloat from sha_crypt. -1130 bytes. |
| 12:23.48 | CIA-2 | cryptpw: add more difficult test vectors. |
| 12:34.31 | mjf_ | so is anyone willing to look at a patch for linuxthreads? |
| 12:37.49 | landley | maybe? |
| 12:37.59 | mjf_ | heh. good enough for me. |
| 12:38.14 | landley | Post it to the list and I'll look at it after I get some sleep. :) |
| 12:38.15 | mjf_ | http://uclibc.org/lists/uclibc/2008-August/019924.html it's this patch that will posted but updated |
| 12:38.18 | mjf_ | ok |
| 12:38.24 | mjf_ | ta |
| 12:38.27 | landley | 0.9.30 is out |
| 12:38.35 | landley | Post fresh copies to the list if it's still needed. :) |
| 12:38.49 | mjf_ | ok |
| 12:39.02 | landley | g'night. |
| 12:55.13 | CIA-2 | 03vda * r24027 10busybox/libbb/pw_encrypt_sha.c: libbb/pw_encrypt_sha: -28 bytes |
| 12:57.50 | *** join/#uclibc hiyuh (n=hiyuh@KD125054017176.ppp-bb.dion.ne.jp) |
| 13:08.27 | blindvt` | mjf_, you broke the whitespace in manager.c |
| 13:09.18 | blindvt` | mjf_, the last hunk in specific.c looks bloaded |
| 13:10.37 | blindvt` | mjf_, why did you rename atomic_{in,de}crement? |
| 13:11.50 | blindvt` | mjf_, those two new guards. What are they supposed to accomplish, why do you think we need them? |
| 13:15.54 | mjf_ | i broke the whitespace? shit. |
| 13:16.26 | blindvt` | mjf_, at least the the #endif in the last hunk |
| 13:16.41 | mjf_ | oh my bad |
| 13:16.47 | blindvt` | s/bloaded/bloated/ |
| 13:17.19 | mjf_ | sec |
| 13:20.34 | blindvt` | mjf_, re those two guards. Generally speaking just because it's in libdrepper does not automatically imply that we want it, fwiw. Especially not if they just end as nil after the CPP but trick people into thinking that they would actually do anything. |
| 13:25.19 | CIA-2 | 03vda * r24028 10busybox/libbb/pw_encrypt_sha.c: libbb: sha_crypt -123 bytes |
| 13:30.29 | blindvt` | mjf_, the SYSVSEM are fine, i suppose. The 2 new guards a unneeded noise AFAICS. the spinlock thing (unfortunately you forgot to add -p to your diff-cmd) sounds somewhat plausible. The specific.c changes do more harm than good. Someone would have to think about the pthread.c hunk that sets signal_jmp if that's ok or not |
| 13:30.58 | blindvt` | mjf_, and the rest is just noise |
| 13:39.53 | mjf_ | the rest was maiinly just to bring it in sync with upstream |
| 13:56.19 | mjf_ | pwd |
| 13:56.21 | mjf_ | oops |
| 13:59.35 | blindvt` | yep, noted |
| 14:00.06 | mjf_ | apart from the whitespace bodge, that was my bad ;-) |
| 14:04.20 | blindvt` | trivial cosmetic nitpick only |
| 14:07.52 | CIA-2 | 03aldot * r24029 10uClibc/Makefile.in: |
| 14:07.52 | CIA-2 | - do not fail if mktemp is not available. |
| 14:07.52 | CIA-2 | <PROTECTED> |
| 15:31.51 | *** join/#uclibc tsukasa (n=tsukasa@unaffiliated/tsukasa) |
| 16:06.27 | ncopa | sigh... i need a uclibc patch to compile gcc-g++ |
| 16:06.41 | ncopa | it complains about clocale |
| 16:09.44 | mjf_ | heh, locales |
| 16:22.05 | *** join/#uclibc wberrier (n=wberrier@12.191.193.40) |
| 16:32.54 | CIA-2 | 03jacmet * r24030 10buildroot/package/busybox/ (10 files): busybox: bump 1.12.x version |
| 16:32.57 | CIA-2 | 03jacmet * r24031 10buildroot/package/busybox/ (4 files): busybox: add 1.13.x, mark older as deprecated |
| 16:41.03 | ncopa | actually i just removed --enable-clocale=uclibc and it worked |
| 16:41.59 | mjf_ | win |
| 16:42.40 | *** join/#uclibc dmead (n=dan@ip226.sensaphone.us) [NETSPLIT VICTIM] |
| 16:50.17 | blindvt` | ncopy, what arch are you using? |
| 16:50.26 | blindvt` | ncopa, what arch are you using? |
| 18:10.50 | solar | blindvt: I think ncopa is x86 based. |
| 18:11.22 | solar | blindvt: so far. 2-3 extra patches needed on .30 ? |
| 18:27.20 | *** join/#uclibc wberrier (n=wberrier@12.191.193.40) |
| 19:01.11 | mjf_ | evening |
| 19:37.32 | *** join/#uclibc pcgeil (n=steffen@p549E5CB9.dip.t-dialin.net) |
| 20:25.25 | *** join/#uclibc Zpenguin (n=Zpenguin@CPE001a70f2faee-CM001371145508.cpe.net.cable.rogers.com) |
| 21:02.58 | *** join/#uclibc tsukasa` (n=tsukasa@unaffiliated/tsukasa) |
| 21:16.10 | *** join/#uclibc pcgeil_ (n=steffen@p549E5E3D.dip.t-dialin.net) |
| 21:51.57 | *** join/#uclibc henux (i=henrih@unaffiliated/henux) |
| 21:53.34 | CIA-2 | 03vda * r24032 10busybox/coreutils/stat.c: stat: fix compile breakage (get_f_fsid() is used even if !FEATURE_STAT_FORMAT) |
| 22:14.04 | *** part/#uclibc henux (i=henrih@unaffiliated/henux) |
| 22:31.18 | *** join/#uclibc tiny (n=ivob@unaffiliated/tiny) |