irclog2html for uclibc on 2002.08.20

00:04:37anderseetzanger: yes
00:05:02tzangerwhat was the cause?  Or what were the causes rather?
00:06:24anderseelots of things.  C++ name mangling.  coding bugs.
00:06:40anderseeWithout specifics the question is meaningless
00:06:41tzangerheh yeah I suppose that was a pretty open-ended question  :-)
00:08:03tzangeruclibc-0.9.14.  no glibc on the system.  no wchar or locale.  I can compile (and use) practically everything, including perl.  However Perl dynamic module loader (dynaloader) cannot resolve symbols properly
00:08:32tzangernow mjn3 tested the same code as I with his copy of uclibc (with locale and wchar) and it seemed to work just fine for him
00:08:41tzangerI'm afraid I don't know much else about his system
00:10:06tzangerIt doesn't seem to have anything to do with ld.so.conf/cache, as I was playing aroudn with perl trying to see if I could "ease into" the problem by talking to dynaloader myself
00:14:21anderseeld.so.conf/cache are not relevant to uclibc
00:14:45tzangerok.  the don't seem to be relevant to DynaLoader even on a glibc system
00:26:54tzangermjn3: what version of uClibc are you running?  CVS?
00:27:54mjn3that... or cvs-to-be    ;-)
00:27:59tzangerheh
00:28:28mjn3currently cvs
00:28:46tzangerwell...  is a cvs snapshot close enough?  I'm lost on this perl dynaloader -- I tried testing the Compress::Bzip2 too but got the exact same errors...  I swear there is *only* uclibc on this system
00:29:55mjn3snapshot should be good enough to pass most of the tests
00:30:12tzangerok
00:30:17tzangerI'll give that a shot I think
00:30:18mjn3i did do an interactive perl config
00:30:37tzangeryeah so did I -- anything out of the ordinary there that you turned on or turned off?  I pretty much went with the flat-out defaults
00:31:29mjn3the main change for me was the location of libc as i recall, but i'm not running a uclibc-only system
00:31:46tzanger*nod* - and perl finds /lib/uclibc.so as the c library
00:35:54mjn3tzanger: are you building on a uclibc-only system?  if so it might be some toolchain issue
00:36:17tzangermjn3: well that's where it gets a little confusing  :-)
00:36:35tzangerI built a static toolset (based on slack8, so glibc, but all static, everything *everything* static)
00:37:05tzangerthen I created a chrooted environment and built uClibc and compiled the toolset all dynamically linked against uclibc
00:37:27tzangerin retrospect I should create a build environment all statically linked against uclibc instead
00:37:46mjn3have you tried using ltrace on perl running one of the failing tests?
00:37:54tzangerno
00:37:56tzangernot yet
00:37:59tzangerI have to compile ltrace :-)
00:42:43tzangerholy shit
00:42:45tzangerthat's a lot of output
00:44:15mjn3indeed...
00:44:26tzangerI don't think I'll paste that to the channel  :-)
00:44:33tzangerI'm familliar with strace output but ltrace is new to me
00:45:32mjn3well people, i'm calling it a day.  later
00:45:40tzangerlater mjn3  thanks for the help
00:45:51mjn3sure
04:09:05WileHaquer\leave
12:07:41tzangerwhee
12:07:46tzangerI get to try CVS uclibc today  :-)
12:10:57anderseeyeah
12:31:10tzangerandersee: would you recommend wchar support?  I personally don't see a need for it but I'm thinking in terms of things breaking without it
12:38:14anderseeerr
12:38:21anderseeyou don't need it, then leave it out...
12:40:16tzangerwell I don't need LFS but e2fsprogs won't compile without it...  that's the type of thing I meant
12:43:34tzangerI spotted this in the CVS install process:
12:43:35tzangerar rv ./tmp/libgcc-need.a
12:43:35tzangerFinding missing symbols in libc.a ...
12:43:35tzanger    partial linking...
12:43:35tzanger../libc.a(getttyent.o): In function `setttyent':
12:43:38tzangergetttyent.o(.text+0x3d7): Oddly enough, __fsetlocking() is NOT threadsafe.
12:46:43anderseeyup
12:46:47anderseeIts true.
12:46:56andersee__fsetlocking() is not threadsafe
12:46:58tzangerok just wanted to make sure I didn't screw something up :-)
12:48:57tzangerhmm I take it the cvs lib isn't binary compatible with 0.9.14  :-)
12:49:18anderseevery true...
12:49:30anderseeSeveral critical structures changed size.
12:49:33tzangerok
12:49:45tzangerI was getting tons of "can't find __xstat" and __xstat64 and so on
12:50:03tzangeris going to be a uclibc compile guru before long if he keep screwing things up at this rate :-)
12:51:24anderseetzanger: yup.  All those *xstat funcs are gone.
12:52:15tzangerwith cvs busybox: what's start-stop-daemon and run-parts?
12:53:47anderseetzanger: there are docs covering such things....
12:54:20tzangerHmm..  I will check again (the help in the menuconfig isn't there, which is why I asked)
12:55:15anderseetzanger: yeah.  I still need to integrate the help into the config system.
12:55:24anderseeHowever the docs _are_ there in the docs dir
12:55:28tzangerah
12:55:30tzangerok
12:55:31tzangermy apologies
12:55:36anderseeno prob
12:55:57anderseeJust easier to point you to the docs then try to spew things here
12:56:01tzangeragreed
13:32:18anderseemorning
13:35:22tzangerhmm
13:35:31tzangerfileutils is barfing about dirent's d_type
13:38:06sjhillg'morning andersee
13:38:40anderseesjhill: did you see all the binary-incompatible header changes yesterday?
13:38:58sjhillandersee: no, yesterday was kernel day, today is toolchain day
13:39:05sjhillandersee: what's up?
13:40:19anderseeChanges to struct stat and firends to match the kernel structs (no more *xstat wrappers).   There is one more change happening today to the shm headers, then with luck I'll push out a bugfix release this afternoon
13:41:42tzangerI think something may be up with LFS in the cvs version -- I have DO_LFS=true but both bzip2 and fileutils aren't compiling unless I disable their detection of large file support
13:46:11tzangerDTTOIF is defined in my build, but I'm not using BSD...
13:49:06mjn3tzanger: LFS behavior has not changed in some time.  also, both perl and python are passing the large file support tests on my box
13:50:10tzangerI'm not *using* lfs but things like bzip2 and fileutils break without it
13:50:27tzangerbzip2 was easy to fix
13:50:42tzangerfileutils is proving harder.  --disable-largefile isn't behaving
13:53:15tzangerI went back and set DOLFS=false and made clean all install for uClibc but the same problem exists.  DTTOIF gets defined
13:53:56tzangerI just #if 0'd the relevant bit in ls.c
13:56:18mjn3which version of fileutils?
13:56:22tzanger4.1
13:59:30tzangergawk won't link (can't find -ldl) even though /usr/lib/libdl.so (and libdl.so.0.9.14) is there
14:00:03tzangeroh wait
14:00:04tzangerduh
14:04:49mjn3andersee: erik, i just saw your post about long long support.  while the drand stuff has been fixed, there are still lots of issues with disabling long long.
14:28:31mjn3andersee: erik, why is libthread_db installed when threads are disabled?
14:35:05anderseemjn3: It is?  Probably because I'm an idiot then.
14:35:10anderseelemme fix that
14:35:26anderseeIt should only be installed when threads and debug are enabled
14:35:53anderseedoh!
14:36:12anderseeYup.  I screwed that one up.  Moved things outside the threads check.
14:38:13mjn3thanks.  at the moment, i'm trying to figure out why fileutils configure is adding -lrt to LIBS
14:38:17anderseeanyway, its fixed now
14:52:09tzangerthere
14:52:19tzangernow I have a statically linked build environment based on uClibc
14:52:25tzangernow let's see if I can't make some headway
15:06:43mjn3tzanger: there is an issue with fileutils with --disable-largefile.  i'll look at it later today.
15:52:06anderseebuilds gcc-3.2
15:57:38tzangerwonders what the different featuresets of vim6.1 are -- no docs
16:03:38tzangertime for perl
16:06:21tzangerThis probably doesn't make sense, but I'm trying to compile a static gawk-3.1.1 and the linker is failing because it can't find -ldl.  now libdl.so is there, but I don't think there is such thing as a static dynamic linker library... is this the cause of my grief?
16:12:30tzangerah
16:12:48tzangerbroken configure assumes that if dynamic library capabilities exist that I want them :-)
16:24:33tzangerbah
16:24:37tzangerperl needs large file support too
16:29:55tzangerandersee: should I be using dld or dlopen for perl's dynamic lib loading with uClibc?
17:03:35tzangerdamn
17:03:40tzangerall that work and I'm no closer
17:03:48tzanger /usr/bin/perl: symbol 'bzBuffToBuffCompress': can't resolve symbol 'L'
17:04:07tzangerinstead of 'funnysymbolL' it's just L now though  :-/
17:12:45tzangermjn3: which dynamic loader did you tell Perl to use?  dlopen is the default for linux but I'm wondering about dld in particular
17:15:38mjn3mjn3@mars:~/work/embedded/fileutils-4.1$ ~/ureadelf ../perl-5.6.1/perl          Type:           EXEC (Executable file)                                          Machine:        Intel 80386
17:15:38mjn3Class:          ELF32
17:15:38mjn3Data:           2's complement, little endian
17:15:38mjn3Version:        1 (current)
17:15:39mjn3OS/ABI:         UNIX - System V
17:15:40mjn3ABI Version:    0
17:15:42mjn3Interpreter:    /home/mjn3/i386-linux-uclibc/lib/ld-uClibc.so.0
17:15:44mjn3Dependancies:
17:15:46mjn3        libdl.so.0
17:15:48mjn3        libm.so.0
17:15:50mjn3        libc.so.0
17:15:52mjn3        libcrypt.so.0
17:16:43tzangeryour interpreter is different than mine
17:16:50tzangerInterpreter:    /lib/ld-linux.so.2
17:17:16tzangerbut that just links to ld-uClibc-0.9.14.so
17:43:18tzangerAHA
17:43:24tzangerI don't know how to fix it yet but I see the problem
17:43:38tzangerfrom the Compress::Bzip2 make process:
17:43:39tzangerLD_RUN_PATH="/lib" cc  -shared Bzip2.o  -o blib/arch/auto/Compress/Bzip2/Bzip2.so   -lbz2
17:43:43tzangerit LOOKS like it's linking it in
17:43:44tzangerbut
17:43:53tzanger# ldd blib/arch/auto/Compress/Bzip2/Bzip2.so
17:43:53tzanger        libc.so.0 => /lib/libc.so.0
17:43:56tzangerno bz2
17:52:51tzangermjn3: when I run ld, should I not be getting the uclibc ld instead of gnu ld?
17:53:14mjn3mjn3@mars:~/work/embedded/fileutils-4.1$ ~/i386-linux-uclibc/usr/bin/ldd ../perl-5.6.1/lib/auto/POSIX/POSIX.so
17:53:14mjn3        libm.so.0 => /home/mjn3/i386-linux-uclibc/lib/libm.so.0
17:53:14mjn3        libc.so.0 => /home/mjn3/i386-linux-uclibc/lib/libc.so.0
17:53:46mjn3mjn3@mars:~/work/embedded/fileutils-4.1$ ~/ureadelf ../perl-5.6.1/lib/auto/POSIX/POSIX.so
17:53:46mjn3Type:           DYN (Shared object file)
17:53:46mjn3Machine:        Intel 80386
17:53:46mjn3Class:          ELF32
17:53:46mjn3Data:           2's complement, little endian
17:53:47mjn3Version:        1 (current)
17:53:49mjn3OS/ABI:         UNIX - System V
17:53:51mjn3ABI Version:    0
17:53:53mjn3Dependancies:
17:53:55mjn3        libm.so.0
17:53:57mjn3        libc.so.0
17:53:59mjn3m
17:55:18tzangerI get the same output mjn3
18:32:39tzangerdo I not need uclibc ld, nm, etc.?  or is it compatible with gcc binutils?
18:32:54tzangereverything so far has been build and linked using binutils
18:38:13mjn3i'd use the uclibc tools
18:38:38tzangerI can't find uclibc's ld, nm, etc...  hell I can't find their source code1
18:38:38mjn3i isolated the fileutils problem, but i need to run an errand.  it should be fixed tonight.
18:40:20mjn3because some of them are just symlinks to the normal ones.  i do PATH=~/i386-linux-uclibc/usr/bin:$PATH {command}
18:40:32tzangerah
19:11:26tzangerok from what I can tell uClibc's ld is just a wrapper for gnu ld and it doesn't do anything at all if glibc isn't present
19:11:36tzangerglibc's gcc wrapper, however may be a different story
19:13:39anderseetzanger: uClibc builds a wrapper toolchain around the toolchain uClibc was built with.
19:14:23tzangerandersee: right.  the ld wrapper just adds -L/a/few/uclibc/dirs -- which doesn't do anything if uClibc is the only c lib on the system
19:14:27anderseetzanger: So you need whatever libraries that toolchain requires.
19:14:48tzangerI'm still decyphering if the gcc wrapper mangles anything wrt dynamic loading
19:15:16anderseeIf you want a native toolchain linked vs uClibc, you will not want to use the wrapper.
19:15:27tzangeroh ok
19:15:37tzangerwell that' what i have  :-)  everything is statically linked against uClibc
19:15:49tzanger-- everything in the toolchain, that is
19:18:21anderseetzanger: k
19:22:51tzangerandersee: have you ever seen the linker not create the correct dependencies?  
19:22:58tzangerLD_RUN_PATH="/lib" cc  -shared Bzip2.o  -o blib/arch/auto/Compress/Bzip2/Bzip2.so   -lbz2
19:23:08tzanger# ldd blib/arch/auto/Compress/Bzip2/Bzip2.so
19:23:08tzanger        libc.so.0 => /lib/libc.so.0
19:23:13tzanger(no libbz2.so.0)
19:23:56tzangerrunning nm on Bzip2.so shows that there are three symbols that are unresolved which pertain to libbz though
19:24:09tzanger# nm blib/arch/auto/Compress/Bzip2/Bzip2.so | grep bz
19:24:09tzanger         U bzBuffToBuffCompress
19:24:09tzanger         U bzBuffToBuffDecompress
19:24:09tzanger         U bzlibVersion

Generated by irclog2html.pl by Jeff Waugh - find it at freshmeat.net! Modified by Tim Riker to work with infobot logs, split per channel and by date, etc.