14:56 < zumbi_> /usr/mips-linux-gnu/bin/ld: skipping incompatible /usr/mips-linux-gnu/lib/libc.so when searching for -lc
14:57 < zumbi_> it happens with other arches too (the arches that have 32/64 bits ABI)
14:59 < zumbi_> i'm currently doing another build, so error log is not yet ready, in sometime it will get back to the error
15:02 < buxy> zumbi_: check /usr/share/perl5/Dpkg/Shlibs.pm if you want to add other directories to look into
15:04 < guillem> something I forgot to comment on the bug report about dpkg-cross support was that I think this is kind of a hack
15:05 < guillem> and I'd really like switching to use multiarch instead
15:05 < guillem> zumbi_: and hi
15:10 < codehelp> buxy: hi, the directory is in /usr/share/perl5/Dpkg/Shlibs.pm but dpkg-shlibdeps appears to find /usr/$crossprefix/lib and bail out
15:11 < codehelp> when it could go on to /usr/$crossprefix/lib32/
15:11 < codehelp> and then bail out if that fails also
15:11 < codehelp> ditto for ../lib64
15:11 < buxy> I doubt this, maybe objdump bails out because it can't parse the files
15:11 < codehelp> ah
15:12 < codehelp> binutils-multiarch is installed
15:12 < codehelp> just checking on objdump
15:18 < codehelp> it's ok - looks like a bug in dpkg-cross
15:18 < codehelp> thanks for your help, buxy & guillem
15:30 < guillem> codehelp: also if we had proper multiarch support, you could stop doing the package name mangling, and path shuffling on those packages
15:31 < guillem> and cross-building would become a more natural and integrated thing
15:37 < codehelp> by proper multiarch support, you mean that the "foreign" binaries from mips would be automatically installed in /mips-linux-gnu/ ?
15:42 < guillem> codehelp: well only libraries (or objects you want to link to) would need that, and those would go into <prefix>/lib/<arch-os>/
15:42 < codehelp> yes, that's it
15:42 < codehelp> guillem: who is looking after multiarch support nowadays?
15:42 < guillem> you don't need crosscompiled binaries installed, those of course can be generated, but as normal packages with the normal target dirs
15:43 < guillem> there's a #multiarch channel and the few web pages
15:43 < codehelp> thanks
15:43 < guillem> codehelp: the problem has been mostly missing support from the toolchain
15:43 < guillem> so the rest has been mostly put on hold
15:43 < codehelp> it's the toolchain that we're working on (zumbi and I) here and next week
15:43 < guillem> last time binutils was missing a patch, and I'm not sure if gcc had a regression recently
15:45 < guillem> codehelp: well the patches are around, they have just not been applied
15:45 < codehelp> that's something I think Emdebian will need to work on for gcc-4.4 and Lenny+1
15:45 < guillem> codehelp: in my mind that be the clean way to get rid of dpkg-cross
15:46 < codehelp> true
15:46 < guillem> codehelp: as I said at the time, I'm fine with the current support in dpkg, as long as it's understood as a temporary workaround
15:46 < guillem> codehelp: there's some links at http://wiki.debian.org/multiarch/
15:47 < codehelp> agreed - but we're coming up against bugs like this where the workaround is showing signs of flakiness
15:47 < codehelp> i.e. a reason to find the fix and implement it
15:50 < codehelp> wouldn't the package renaming still be needed, guillem?
15:50 < codehelp> even with multiarch, dpkg -l will need to show that libc6 and libc6-mips-cross is installed/
15:50 < codehelp> even if we change the way the renaming takes place
15:50 < guillem> codehelp: supposedly once dpkg support multiarch you would be able to install both at the same time
15:51 < codehelp> how to tell that one is installed but one is not?
15:51 < guillem> codehelp: the tuple to distinguish the packages would include the arch for multiarch packages
15:53 < guillem> codehelp: Mithrandir already implemented initial multiarch support for dpkg long time ago
15:53 < codehelp> as a branch?
15:54 < guillem> there's a patch in the bts I think
15:57 < codehelp> I can see #324546 and #369507 - from Goswin - are those what you are thinking of?
16:00 < guillem> I've the patch on my home machine, probably took it from somewhere else then
16:03 < codehelp> ok - if you can find it, it would be handy if you could send to me - we'll take a look at it next week
16:03 < codehelp> (Emdebian WorkSession in Cambridge all next week so lots of available dev time)
16:04 < guillem> yeah sure, or even to one of those bug reports if it's not there, will check later
16:09 < zumbi_> btw, guillem think about extremadura worksession
16:17 < zumbi_> guillem: is #369064 what you are talking about?

---

23:21 < mrvn> zumbi_: no mail found
23:21 < zumbi_> i wrote a follow up to your bug report
23:21 < zumbi_> on binutils multiarch
23:22 < zumbi_> 369064
23:22 < mrvn> zumbi_: ahh, that would be in "bugs" then.
23:23 -!- ifvoid|0120804 is now known as ifvoid
23:24 < mrvn> zumbi_: that doesn't include /s390x-linux-gnu/lib nor 
              /usr/s390x-linux-gnu/lib
23:25 < mrvn> zumbi_: and multiarch would be /lib/s390x-linux-gnu and 
              /usr/lib/s390x-linux-gnu
23:25 < AzaTht> mrvn: didn't get any reply before
23:25 < mrvn> zumbi_: are you sure that patch works at all?
23:26 < zumbi_> mrvn: it used to do its job for what it was meant
23:26 < zumbi_> i suggest you to sent your patches to binutils upstream
23:27 -!- christoph [~christoph@f049032020.adsl.alicedsl.de] has quit 
          [Quit: Verlassend]
23:27 < AzaTht> mrvn: any chance I could see your script?
23:27 < AzaTht> or is it #er-seecret prop-code
23:27  * zumbi_ would like to see multiarch running 
23:28 < zumbi_> AzaTht: one think at a time... people is not multitask :-)
23:28 < zumbi_> s/think/thing
23:28 < AzaTht> zumbi_: prio queue
23:28 < AzaTht> ?
23:29 -!- streuner [~streuner@p54A5E32E.dip.t-dialin.net] has quit [Quit: 
          Verlassend]
23:30 < mrvn> AzaTht: http://mrvn.homeip.net/filter-dctrl/
23:30 < mrvn> AzaTht: go nuts
23:31 < mrvn> zumbi_: If we allow the namespace pollution of the 
              cross-compile dirs for multiarch then I guess we can live 
              with your patch too.
23:31 < mrvn> zumbi_: can you paste an ldscript example output? I'm not 
              sure what dirs would get added overall.
23:32 < helix> are you using that as a smiley?
23:32 < ari> OGC
23:33 < zumbi_> mrvn: it adds /lib64/ dirs
23:33 < mrvn> zumbi_: but not lib?
23:33 < AzaTht> thanks
23:34 < zumbi_> yes, lib as weel
23:34 < zumbi_> s/weel/well
23:34 < mrvn> zumbi_: but not the /s390x-linux-gnu/lib[64] dirs, right?
23:35 < helix> hi ari
23:35 < zumbi_> those too, at least for cross compiling gcc it did well 
                for all official debian arches
23:36 < AzaTht> helix: me? yes
23:36 < helix> ok
23:36 < zumbi_> anyway, do you want to rework all that and try a testcase 
                for multiarch?
23:36 < zumbi_> i can do some work during the weekend and next week
23:37 < mrvn> zumbi_: One problem remains though. On i386 it uses 
              /usr/i486-linux-gnu/lib and on amd64 (32bit) it uses 
              /usr/i386-linux-gnu/lib.
23:37 < zumbi_> yes
23:37 < mrvn> zumbi_: That is the other patch in my bugreport.
23:37 < mrvn> How do you solve that?
23:37 < Manoj> heh. 
http://buildd.debian.org/fetch.cgi?pkg=setools;ver=3.3.4.ds-3.1;arch=alpha;stamp=1212150215
23:37 < zumbi_> ummm.. that is why amd64<->i386 toolchain fails
23:38 < mrvn> zumbi_: one could just link i386-linux-gnu -> i486-linux-gnu
23:38 < Manoj> if they had asked, I would have told them that a 
               simplistic solution like that does not work
23:38 < Manoj> Hmm. it did work on mipsel, though ...
23:39 < zumbi_> mrvn: in my case i did not really care much about that 
                arches, but it is something that has been hanging arround
23:39  * Manoj looks deeper
23:40 < Manoj> so. http://buildd.debian.org/build.cgi?pkg=setools
23:41 -!- streuner [~streuner@p54A5E32E.dip.t-dialin.net] has joined 
          #debian-devel
23:41 -!- esaym [~user@cpe-70-120-89-6.satx.res.rr.com] has quit [Remote 
          host closed the connection]
23:42 < Manoj> no patch in BTS. no mail to me. and a NMU that does not 
               fix the bug, even though they closed it.
23:42 < Manoj> so, no test whether they actually fixed the bug or not.
23:42 < zumbi_> mrvn: now, i'm having some trouble with mips triarch and 
                some other arches.. see 
http://www.emdebian.org/~zumbi/toolchain/unstable-toolchain-amd64/logs//amd64-mips-4.3.log (quitte big file)
23:43 < mrvn> zumbi_: do they even have different TOOL_LIB strings?
23:44 < mrvn> /usr/mips-linux-gnu/bin/ld: /usr/mips-linux-gnu/lib/crti.o: 
              ABI is incompatible with that of the selected emulation
23:44 < mrvn> zumbi_: looks like gcc gets the wrong path.
23:44 < zumbi_> /usr/mips-linux-gnu/bin/ld: skipping incompatible 
                /usr/mips-linux-gnu/lib/libc.so when searching for -lc
23:44 < mrvn> zumbi_: That is fine as long as it eventually finds one.
23:44 < zumbi_> it should look under /usr/mips-linux-gnu/bin/ld: skipping 
                incompatible /usr/mips-linux-gnu/lib32/libc.so when 
                searching for -lc
23:45 < zumbi_> rm last line
23:45 < zumbi_> it should look under /usr/mips-linux-gnu/lib32/libc.so 
23:45 < zumbi_> but it doesn't
23:45 < mrvn> zumbi_: for n32?
23:45 < zumbi_> yes
23:46 < mrvn> isn#t lib32 for o32?
23:46 < zumbi_> no
23:46 -!- schasi [~schasi@p54A27651.dip.t-dialin.net] has joined 
          #debian-devel
23:46 < zumbi_> are you sure
23:46 < zumbi_> i believe lib is for o32 and lib32 for n32 and lib64 for 
                n64
23:46 < mrvn> zumbi_: it should look in something like 
              /usr/mipsn32-linux-gnu/lib/
23:47 < zumbi_> but that would be another new arch
23:47 < mrvn> For multiarch you need uniq TOOL_LIB strings for every abi.
23:47 < Manoj> what is the quick way to find who uploaded a package?
23:47 < mrvn> zumbi_: the lib32 and lib64 dirs are just ugly hacks.
23:48 < zumbi_> yes - that is exactly the problem i'm facing right now
23:48 < mrvn> Manoj: read the changes file
23:48 < Manoj>  Maintainer: Manoj Srivastava <srivasta@debian.org>        

23:48 < Manoj>  Changed-By: Arthur Loiret <arthur.loiret@gmail.com>       

23:48 < zumbi_> mrvn: that is the reason why i want multiarch
23:48 < mrvn> Manoj: and signed by?
23:48 < mrvn> zumbi_: for the mips arch someone has to extend the 
              TOOL_LIB thing in binutils to make it uniq for each abi.
23:49 < zumbi_> what about powerpc
23:49 < Manoj> mrvn: there is none, so perhaps arthur.loiret@gmail.com is 
               the one who uploaded it?
23:49 < mrvn> zumbi_: powerpc64-linux-gnu or ppc64-linux-gnu
23:49 < zumbi_> do you need to do that work as well for the 32 and 64 ABIs
23:49 < zumbi_> powerpc64-linux-gnu
23:49 < mrvn> s390 and s390x, sparc and sparc64, i486 and x86_64
23:50  * Manoj sends a notfixed and a found message to control
23:50 < MadCoder> Manoj: who-uploads
23:50 < mrvn> I think only mips doesn't have one arch per abi
23:50 -!- MoDaX [~nth@lan-84-240-22-131.vln.skynet.lt] has quit [Remote 
          host closed the connection]
23:51 < mrvn> zumbi_: anyway, the "when searching for -lc" just means it 
              found the bad one first. If it continues that means it 
              eventually found a good one.
23:51 < zumbi_> mrvn: so that needs to be implemented on binutils?
23:51 < mrvn> zumbi_: yes.
23:51 < Manoj> MadCoder: Hmm. who-uploads is taking a while.
23:51 < zumbi_> no patches arround?
23:51 < mrvn> zumbi_: never looked at it.
23:51 -!- sabdfl [~sabdfl@87-194-36-33.bethere.co.uk] has joined 
          #debian-devel
23:51 < Manoj> heh. maks. Why am I not surprised.
23:52 < mrvn> zumbi_: isn't mips n64 mips64-linux-gnu?
23:52 -!- zack [~zack@did75-20-88-183-33-56.fbx.proxad.net] has quit 
          [Quit: Leaving.]
23:52 < MadCoder> Manoj: of course it does, it grabs things on d-d-c 
                  archives IIRC or sth similar
23:52 < zumbi_> mrvn: yes, and i guess n32 is mipsn32
23:52 < mrvn> zumbi_: then you just have to get that corrected in 
              genscript.sh
23:53 < mrvn> zumbi_: That might be the same problem that causes amd64 to 
              have i386-linux-gnu. There is no way to pass the right arch 
              into the build and it has some strings hacked in for 
              multilib.
23:54 < mrvn> zumbi_: as a test you could edit the ldscripts. I think for 
              not o32 abi it should still parse the files.
23:56 -!- zack [~zack@did75-20-88-183-33-56.fbx.proxad.net] has joined 
          #debian-devel
23:56 -!- MoDaX [~nth@lan-84-240-22-131.vln.skynet.lt] has joined 
          #debian-devel
23:56 < zumbi_> mrvn: what do you mean?
23:57 < mrvn> zumbi_: edit /usr/lib/ldscripts/elf_mipsn32.*
23:57 < zumbi_> let's go step-by-step
23:57 < mrvn> or maybe first check with strace -f if it opens a file in 
              /usr/lib/ldscripts
23:57 < zumbi_> where should i start to have multiarch working? on 
                binutils?
23:57 < mrvn> zumbi_: yes
23:59 < zumbi_> add /lib/<arch_abi> and /usr/lib/<<rch_abi>
23:59 < zumbi_> by arch_abi i mean arches called by "ABI names"
Day changed to 31 mai 2008
00:00 < mrvn> zumbi_: first fix it so it uses the right arch as in 
              mipsn32-linux-gnu
00:00 < zumbi_> ok - i have the help of your patches
00:01 -!- mind [~mind@host-84-222-13-183.cust-adsl.tiscali.it] has joined 
          #debian-devel
00:01 < zumbi_> then, glibc and gcc already include multiarch, so we have 
                a toolchain
00:01 < zumbi_> then we start to work with dpkg
00:01 < zumbi_> sounds right?
00:01 < mrvn> zumbi_: gcc only needs the support for 
              /usr/include/arch-os-libc/ and it already has that. Check 
              that it works for mips, mipsn32 and mipsn64.
00:02 < mrvn> Then you need to pick one library package and convert it to 
              use the new dirs.
00:04 < mrvn> zumbi_: Then for dpkg you need the following: 1) allow 
              different archs, 2) extend the db to allow multiple 
              packages with the same name but different arch, 3) figure 
              something out for /usr/share/doc/package, 4) fix the 
              depends resolver to use the arch and Multi-Arch: yes|no 
              field.
00:05 -!- d0rt [~ni@69.37.102.188] has joined #debian-devel
00:05 < mrvn> 5) add the arch to /usr/lib/dpkg/info/package*
00:06 < zumbi_> guillem and some other people can help on that
00:06 < zumbi_> maybe you are interested as weel
00:06 < mrvn> Not this week. But in general yes.
00:07 < zumbi_> ok, we can not do that in one day, i guess :-)
00:08 < mrvn> zumbi_: 5 will need some discussion with dpkg. It should be 
              compatible with what we have now and reversible.
00:09 < mrvn> 2 and 4 are the really hard parts.

---