| 00:03.57 | ashes | 1 sec |
| 00:04.37 | ashes | make CC="gcc -Wl,--dynamic-linker,/lib/ld-uClibc.so.0 /lib/libc.so.0" \ -C utils |
| 00:04.39 | ashes | make -C utils install |
| 00:04.47 | ashes | erm |
| 00:05.03 | ashes | make CC="gcc -Wl,--dynamic-linker,/lib/ld-uClibc.so.0 /lib/libc.so.0" -C utils && make -C utils install |
| 00:06.52 | ashes | add -isystem to that maybe too |
| 00:07.08 | ashes | "-isystem include/" |
| 00:08.09 | ashes | if there's an error from that, try 'make headers' first |
| 00:15.55 | *** join/#uclibc mtr_ (n=Michael@kobz-590ca0bd.pool.einsundeins.de) |
| 00:19.47 | JockeHome | ashes: That /lib/libc.so.0 doesn't work |
| 00:20.37 | JockeHome | powerpc-linux-gcc: /lib/libc.so.0: No such file or directory |
| 00:20.46 | ashes | where is your libc.so installed? |
| 00:21.43 | CIA-10 | 03vda * r17175 10busybox/ (coreutils/diff.c coreutils/sort.c testsuite/sort.tests): (log message trimmed) |
| 00:21.43 | CIA-10 | diff: small optimizations; do not try to diff non-seekable stream |
| 00:21.43 | CIA-10 | (currently we don't support that) |
| 00:24.50 | CIA-10 | 03vda * r17176 10busybox/coreutils/diff.c: work around gcc's false warning |
| 00:28.48 | JockeHome | ashes: weel, since this is a buildroot xcompile its in .../staging_dir/lib |
| 00:28.59 | JockeHome | s/weel/well |
| 00:29.30 | JockeHome | don't think I can use that :) |
| 00:29.41 | ashes | give the full path to the libc.so |
| 00:29.58 | ashes | i think it'll work. ld.so will resolve it to /lib after |
| 00:30.39 | ashes | or even lib/libc.so in the uclibc source |
| 00:31.32 | JockeHome | that works, but it also works withot libc.so.0 at all |
| 00:32.11 | ashes | without libc.so.0 what does 'readelf -l' say? |
| 00:32.26 | ashes | readelf -l utils/ldconfig |
| 00:32.42 | ashes | libc.so.6 ? |
| 00:33.14 | ashes | readelf -d |
| 00:33.15 | ashes | even |
| 00:33.27 | ashes | 'Shared library' field |
| 00:33.54 | JockeHome | just libc.so.0 in both cases |
| 00:34.12 | ashes | k |
| 01:24.13 | CIA-10 | 03vda * r17177 10busybox/ (6 files in 2 dirs): |
| 01:24.13 | CIA-10 | add arp applet - thanks to |
| 01:24.13 | CIA-10 | "Eric Spakman" <E.Spakman@inter.nl.net> |
| 02:05.05 | *** join/#uclibc wrobbie (n=rob@cm74.kappa84.maxonline.com.sg) |
| 03:55.11 | *** join/#uclibc blindvt__ (n=bf@62.47.130.172) |
| 03:57.27 | *** join/#uclibc blindvt (n=bf@62.47.131.19) |
| 07:28.07 | *** join/#uclibc ashes (n=ashes@modemcable085.56-130-66.mc.videotron.ca) |
| 08:57.54 | Mirell | ... BSD's sed uses -E, GNU's sed uses -r. |
| 11:56.38 | *** join/#uclibc blindvt_ (n=bf@M1013P009.adsl.highway.telekom.at) |
| 12:03.58 | *** join/#uclibc blindvt__ (n=bf@M855P008.adsl.highway.telekom.at) |
| 12:19.01 | CIA-10 | 03aldot * r17178 10busybox/scripts/defconfig: - add arp to defconfig |
| 13:05.45 | *** join/#uclibc wrobbie (n=rob@cm74.kappa84.maxonline.com.sg) |
| 15:19.38 | CIA-10 | 03aldot * r17179 10busybox/testsuite/taskset.tests: - pull taskset.tests from the busybox_scratch branch |
| 15:53.20 | CIA-10 | 03aldot * r17180 10busybox/include/usage.h: - a few minor tweaks |
| 15:53.40 | *** join/#uclibc vapier (i=UserBah@wh0rd.org) |
| 15:53.48 | vapier | ashes: ping |
| 15:56.10 | CIA-10 | 03aldot * r17181 10busybox/coreutils/diff.c: (log message trimmed) |
| 15:56.10 | CIA-10 | - FIXME: someone broke diff -r |
| 15:56.10 | CIA-10 | - minor shrinkage i had lying around |
| 16:11.03 | blindvt | mjn3, ping |
| 16:13.53 | mjn3 | blindvt, yes? |
| 16:14.47 | blindvt | mjn3, i have some severe trouble with the GETC/PUTC_MACRO options: |
| 16:14.57 | blindvt | ../../../toolchain_build_i586/gcc-4.2/gcc/errors.c:68: undefined reference to `__fputc_unlocked' |
| 16:15.06 | blindvt | for example. |
| 16:16.01 | blindvt | mjn3, i want to know what you wanted to achieve with the macros.. I have this untested draft-patch, that doesn't remove them but tries to beat them to behave: |
| 16:16.08 | blindvt | mompls.. copying.. |
| 16:17.12 | blindvt | mjn3, http://uclibc.org/~aldot/uClibc-0.9.29-fix-fget_putc.diff |
| 16:17.55 | blindvt | mjn3, the alternative approach is to remove the defines for fget/putc_unlocked, so i at least don't have to #undef them internally. |
| 16:18.58 | blindvt | mjn3, alternatively, i'm tempted to wipe those two config option and just always call the libc_hidden_proto(fget/putc_unlocked) internally. |
| 16:19.04 | blindvt | mjn3, what do you think? |
| 16:23.43 | mjn3 | i think it is another example of the kinds of namespace breakage psm introduced into svn... and i'll waste no time on fixing svn issues. my position for some time has been that we should relable svn as a broken branch and start over again at .28, porting things over from svn as appropriate |
| 16:24.09 | mjn3 | so... do whatever you want with svn. i stopped caring about it a long time ago |
| 16:28.08 | mjn3 | but... if you want to know what the intention of those macros was |
| 16:28.24 | blindvt | mjn3, it was purely a speed-tweak, no? |
| 16:28.41 | mjn3 | it was fairly common practice in libc implementations to provide those as macros and avoid a function call |
| 16:28.59 | mjn3 | but i made that use optional. hence the config option |
| 16:29.47 | mjn3 | technically, ansi-std libc functions are not supposed to polute the namespace available to the app |
| 16:29.49 | blindvt | mjn3, well, the function call is still there as a fallback if the macro didn't trigger. That very fallback-function call give me grief |
| 16:30.12 | mjn3 | you're only allowed to use the symbols reserved by the ansi/iso spec |
| 16:30.28 | mjn3 | that's why the macros used the "__" prefixed versions of the unlock functions |
| 16:31.21 | blindvt | mjn3, yes. but the fgetc_unlocked and fputc_unlocked are spec'ed function names, so have to be provided anyway |
| 16:31.35 | mjn3 | they're POSIX... not ANSI/ISO |
| 16:33.09 | blindvt | mjn3, yes, POSIX, you're right |
| 16:34.22 | mjn3 | so... one solution would be to create hidden versions of __f{get|put}c_unlocked for internal use, while also keeping externally visible versions |
| 16:47.04 | solar | wow now theres a face I've not seen in a while.. Hi mjn3 |
| 16:47.09 | mjn3 | hi solar |
| 16:51.02 | mjn3 | oops... look at the time. back in a couple of hours |
| 17:10.11 | *** join/#uclibc pogo123 (n=Miranda@ip142.169.1211H-CUD12K-03.ish.de) |
| 18:10.44 | *** join/#uclibc zindel (n=kvirc@ip210-225.telenet.dn.ua) |
| 18:11.18 | *** part/#uclibc zindel (n=kvirc@ip210-225.telenet.dn.ua) |
| 19:35.13 | CIA-10 | 03vda * r17182 10busybox/networking/arp.c: I *always* forgotting svn add |
| 19:37.43 | CIA-10 | 03vda * r17183 10busybox/archival/gzip.c: (log message trimmed) |
| 19:37.44 | CIA-10 | a ton of gzip changes, split up in compiled and |
| 19:37.44 | CIA-10 | run-tested pieces. Code was rather messy. |
| 19:38.07 | CIA-10 | 03vda * r17184 10busybox/archival/gzip.c: gzip cleanup part #2 |
| 19:38.27 | CIA-10 | 03vda * r17185 10busybox/archival/gzip.c: gzip cleanup part #3 |
| 19:38.44 | CIA-10 | 03vda * r17186 10busybox/archival/gzip.c: gzip cleanup part #4 |
| 19:39.03 | CIA-10 | 03vda * r17187 10busybox/archival/gzip.c: gzip cleanup part #5 |
| 19:39.35 | CIA-10 | 03vda * r17188 10busybox/archival/gzip.c: gzip cleanup part #6 |
| 19:39.55 | CIA-10 | 03vda * r17189 10busybox/archival/gzip.c: gzip cleanup part #7 |
| 19:40.18 | CIA-10 | 03vda * r17190 10busybox/archival/gzip.c: gzip cleanup part #8 |
| 19:40.36 | CIA-10 | 03vda * r17191 10busybox/archival/gzip.c: gzip cleanup part #9 |
| 19:40.54 | CIA-10 | 03vda * r17192 10busybox/archival/gzip.c: gzip cleanup part #10 |
| 19:41.13 | *** join/#uclibc randomguy (n=randomgu@202.92.broadband7.iol.cz) |
| 19:42.03 | hiyuh | lol |
| 19:44.37 | CIA-10 | 03vda * r17193 10busybox/archival/gzip.c: gzip cleanup part #11 |
| 19:45.00 | CIA-10 | 03vda * r17194 10busybox/archival/gzip.c: gzip cleanup part #12 |
| 19:45.52 | CIA-10 | 03vda * r17195 10busybox/archival/gzip.c: gzip cleanup part #13 - the last for today I think |
| 20:03.25 | *** join/#uclibc landley (n=landley@c-71-206-197-43.hsd1.pa.comcast.net) |
| 20:12.07 | mjn3 | back |
| 20:19.26 | *** join/#uclibc blindvt (n=bf@62.47.136.10) |
| 20:23.33 | *** join/#uclibc landley_ (n=landley@c-71-206-197-43.hsd1.pa.comcast.net) |
| 21:25.13 | CIA-10 | 03vda * r17196 10busybox/networking/httpd.c: httpd: stop adding our own "Content-type:" to CGI output |
| 21:26.38 | landley | Is lib/interp.c still needed? |
| 21:34.33 | ashes | pong vapier |
| 21:35.42 | landley | Don't shared libraries get their library loader path from the toolchain that builds them? |
| 21:36.04 | landley | And these days standard practice is to build a toolchain that gives the right information? |
| 21:36.33 | landley | This manual override went in in 2002. (svn 4229, or possibly cvs back then). |
| 21:36.41 | landley | I'm wondering if it's still relevant? |
| 22:12.05 | landley | Hmmm... sequencing. |
| 22:12.16 | landley | This is the initial build with the host toolchain. |
| 22:12.37 | CIA-10 | 03aldot * r17197 10busybox/networking/arp.c: - style fixes and shrink by another 4 bytes while at it. |
| 22:12.39 | landley | Why do the libraries care about their shared library loader? Unless you dlopen() them, they're already being called _from_ a shared library loader, right? |
| 22:20.36 | CIA-10 | 03vda * r17198 10busybox/networking/arp.c: arp: small fixes for user-supplied device name case |
| 22:21.23 | ashes | they need to know what to call to open libraries they depend on. maybe its feasable to have two or more dynamic loaders |
| 22:22.25 | ashes | a main program is linked to library A with libc.so.2. library A is depends on library B. both library A and B were linked with libc.so.1 |
| 22:22.32 | ashes | erm |
| 22:22.42 | ashes | ld.so.1 and ld.so.2 |
| 22:23.06 | landley | So the currently running dynamic loader for the executable won't recursively resolve dependencies in the libraries it loads? |
| 22:23.39 | CIA-10 | 03vda * r17199 10busybox/networking/arp.c: |
| 22:23.39 | CIA-10 | Previous "fix" wasn't good enough. |
| 22:23.39 | CIA-10 | Now *this* is the correct fix (I think). |
| 22:23.40 | ashes | it would make more sense to me if it's that way |
| 22:24.34 | ashes | its more flexable |
| 22:25.37 | landley | It would make more sense to you to have the dynamic loader load more instances of the dynamic loader? Or more sense to work recurisvely? |
| 22:26.10 | landley | Can you link the same program against both elf and non-elf shared libraries? |
| 22:26.18 | ashes | if it's the same version then it would already be in shared memory |
| 22:27.08 | ashes | im not sure about non-elf |
| 22:28.05 | ashes | working recurisvely works fine if you do not want reverse compatability, and don't have rare software that has a propriety loader |
| 22:29.59 | ashes | something like xorg might want to use its own dynamic loader |
| 22:30.24 | landley | For the executable, or for a shared library? |
| 22:30.39 | landley | There's no problem using your own dynamic loader. Link your executable with it. |
| 22:30.55 | landley | My question is why you'd want to use a different dynamic loader to load a dependent library. |
| 22:30.59 | ashes | between libraries i guess |
| 22:31.06 | landley | The information is in the wrong place. "This library needs to be loaded with this shared library loader". |
| 22:31.14 | landley | That information is not in the library, it's in the things the library is linked against. |
| 22:31.33 | ashes | it would be tricky and i never heard of it. im just guessing at the usefullness of having two actively used dynamic loaders |
| 22:31.35 | landley | An executable can only specify one library loader. You'd need to create a wrapper library to load the other library and hope it worked. |
| 22:32.03 | landley | ashes: it really doesn't sound like something that's ever actually been tested, and I'm trying to think of a situation where it would be useful. |
| 22:32.20 | ashes | my first example |
| 22:32.30 | ashes | for reverse compat |
| 22:34.32 | landley | ashes: library symbol version is something glibc implemented, but which turned out not to actually work. I remember that. :) |
| 22:35.00 | landley | These days, libraries have the version as the last part of the name, and if you care about a specific version you include it in the name. |
| 22:35.13 | landley | I'm not sure what your first example was trying to say. |
| 22:37.46 | ashes | bash is linked to ld-glibc.so and libc.glibc.so. bash is also linked to libreadline.so which was linked to ld-uclibc.so and libc.uclibc.so |
| 22:38.20 | landley | ashes: the suckage of that scenario is deep and impressive. |
| 22:38.39 | landley | This sort of thing is why they invented static linking. |
| 22:38.44 | ashes | it's bizzare, but its nice to have the option |
| 22:38.49 | landley | Even if support for this is implemented, I really wouldn't expect it to work. |
| 22:39.36 | landley | You have the same symbols occurring in multiple different contexts. Now add things like "weak" into the mix and watch the fireworks. |
| 22:41.17 | ashes | in the real world we could probably get-ld.so-from-parent |
| 22:41.43 | ashes | instead of hard coding it in each library |
| 22:42.36 | ashes | libc, cc, and ld would all need to be modified though |
| 22:45.57 | landley | ashes: why? Just ignore the unused field. |
| 22:46.28 | landley | The uClibc ld-uClibc.so can act recursively. When it loads a library and resolves the symbols, it doesn't have to hand off to another one, it can just resolve any remaining symbols itself recursively. |
| 22:46.32 | landley | (Unless I'm missing something.) |
| 22:46.55 | landley | It's the library loader that _does_ it, correct? |
| 22:50.21 | ashes | i think everyone expects libraries to reload ld.so, and so ld.so won't automatically start loading library dependencies. i dont think the code exists in the libraries to tell it to look to the parent executable for the dynamic loader |
| 22:51.17 | ashes | the way things are now, i think if the library doesn't know where ld.so is then it fails |
| 22:53.43 | landley | Which of uClibc's libraries actually depend on other libraries? Hmmm... |
| 22:54.53 | ashes | the ld.so version is closely related to the libc.so version and api. if you take a library, which doesn't have a hardcoded ld.so name, from a uclibc system and copy it on a glibc system i dont think it works |
| 22:56.19 | ashes | hardcoding the ld.so name is the safest way of being sure the library is using the correct loader/libc version |
| 22:57.25 | ashes | libraries are also linked to libc.so, that doesn't mean libc.so is reloaded because its already in shared memory |
| 22:59.55 | ashes | and |
| 23:00.09 | ashes | mm |
| 23:00.37 | ashes | nm, i thought of another example but its almost the same |