/srv/irclogs.ubuntu.com/2005/08/12/#ubuntu-toolchain.txt

lamontglibc patch inbound from patofiero12:20
lamontjbailey: debian and ubuntu will want it.. :-(12:20
lamontfabbione: fwiw, this appears to be "the librsvg2" bug that I've been hitting12:52
jbaileylamont: Sounds lovely.01:19
jbaileyOoo, good timing for being back at the terminal. 01:20
jbaileydebhelper pass for gcc-4.001:20
jbaileyPerhaps I got the biarch stuff right on the first pass for it. =)01:20
jbaileyOr not.  *sigh*  No lib64gcc1.01:22
lamontjbailey: patch is trivial: comment out glibc234-hppa-remove-mallocdef01:25
lamonttest builds running now01:25
jbaileylamont: Thanks for taking care of it.01:25
lamontwell, patofiero is doing a debian build, and I'm doing a breezy build01:25
lamontyou want I should upload once I finish testing?01:25
lamontpatch only modifies linuxthreads/sysdeps/unix/sysv/linux/hppa/malloc-machine.h, so I think the other architectures are safe. :-)01:26
jbaileyNo, please don't.01:27
jbaileyI'm in the middle of working up the biarch toolchain for amd64.01:27
jbaileyMy glibc is basically set at this point, so if I can avoid rerunning it, I'd rather.01:27
jbaileyI just need to do gcc-4.0 and then I can hand it to you.01:27
jbaileyYAR, found the spot that I missed.01:31
jbaileyI am in a maze of twisty debian/rules files, all alike.01:32
jbaileyWill run the testsuite with -m64: yes01:36
jbaileyMuch better.01:36
jbaileyBack in another 3 hours, I guess.01:36
lamontjbailey: ah, ok.  your soon-to-be-biarch upload will comment out the patch I loathe as well? (assuming that my testing says so)?01:44
=== lamont will be back in ~ 4.5 hours or so, give or take
jbaileylamont: I guess it can easily enough.02:04
jbaileyI had hoped for a no-op upload, but if it's important.02:04
jbaileyI have to repeat this process for amd64/i386 biarich right after, too02:05
=== martin [~freenode@220-253-54-93.VIC.netspace.net.au] has left #ubuntu-toolchain []
=== ajmitch_ [~ajmitch@port163-24.ubs.maxnet.co.nz] has joined #ubuntu-toolchain
jbaileyHmph04:56
jbaileygcc-4.0 doesn't b uild in 64 bit mode.  Too drunk to fix it now:04:56
jbailey/tmp/gcc-4.0/gcc-4.0-4.0.1/build/gcc/xgcc -B/tmp/gcc-4.0/gcc-4.0-4.0.1/build/gcc/ -B/usr/i486-linux-gnu/bin/ -B/usr/i486-linux-gnu/lib/ -isystem /usr/i486-linux-gnu/include -isystem /usr/i486-linux-gnu/sys-include -m64 -DHAVE_CONFIG_H -I. -I../../../../src/libmudflap -I. -Wall -ffunction-sections -fdata-sections -O2 -g -O2 -m64 -MT mf-runtime.lo -MD -MP -MF .deps/mf-runtime.Tpo -c ../../../../src/libmudflap/mf-runtime.04:57
jbaileyc  -fPIC -DPIC -o .libs/mf-runtime.o04:57
jbailey../../../../src/libmudflap/mf-runtime.c:167: error: conflicting types for '__mf_lc_mask'04:57
jbailey../../../../src/libmudflap/mf-runtime.h:19: error: previous declaration of '__mf_lc_mask' was here04:57
jbaileyI'll try in the morning. =)04:57
lamontjbailey: the bug in question is blocking a whole bunch of packages05:17
lamontin both debian and ubuntu05:17
lamontand wedges the buildd outside of timeouts when it trips...05:17
=== lamont tests the fix
lamontjbailey: dropping that patch fixes the issue.  could you upload it, and also push through getting the same change in debian?  Want a grave bug to use?05:20
lamontmeanwhile, I have this crontab entry that I really don't like....05:22
lamont0 */3 * * * sudo killall -9 gdk-pixbuf-query-loaders >/dev/null 2>&105:22
=== elmo [~james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #ubuntu-toolchain
=== elmo [~james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #ubuntu-toolchain
=== doko [~doko___@dsl-084-059-068-056.arcor-ip.net] has joined #ubuntu-toolchain
=== fabbione would love to get a fixed binutils for sparc soon
=== fabbione wonders how complicate would be to package the crosstools
fabbionethe amount of packages that come out of that are impressive..08:52
fabbionebut that would be great fun :)08:52
dokojbailey: just disable the 64bit mudflap at the moment, we don't have it packaged anyway09:04
dokojbailey:10:34
doko@@ -93,7 +93,7 @@10:34
doko                > debian/$(p_l64gcc).substvars10:34
doko else10:34
doko   ifeq ($(DEB_TARGET_ARCH),i386)10:34
doko-       echo 'shlibs:Depends=amd64-libs (>= 0.1)' \10:34
doko+       echo 'shlibs:Depends=libc6-amd64-dev (>= 2.3.5-1ubuntu8)' \10:34
doko                > debian/$(p_l64gcc).substvars10:34
doko   else10:34
doko     ifeq ($(DEB_TARGET_ARCH),powerpc)10:34
dokoshould be libc6-amd64, not libc6-amd64-dev. the version isn't really needed10:35
=== Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain
doko-- Jeff Bailey <doko@ubuntu.com>  Sat,  6 Aug 2005 16:06:44 +000011:38
dokosplit personality ...11:39
dokoUnpacking libglu1-mesa-dev (from .../libglu1-mesa-dev_6.2.1-5ubuntu4_i386.deb) ...02:28
dokodpkg-deb: subprocess paste killed by signal (Broken pipe)02:28
dokoE: Sub-process /usr/bin/dpkg received a segmentation fault.02:28
dokoapt-get failed.02:28
dokoPackage installation failed02:28
dokolamont, infinity: ^^^ during the openoffice.org build on i38602:28
jbaileydoko: Yeah, I saw the email address, apparently dch coudoln't figure mine out in the chroot so assumed the same one as before. =)04:44
jbaileyThanks for the other two hints.04:45
dokojbailey: I sent you an email about the merged stuff04:45
jbaileylamont: Will regen with that patch.04:45
jbaileydoko: Cool, thanks.04:46
jbaileyI've just crawled out of bed, so I'm moving a bigt slowly.04:46
jbaileydoko: Cool, so I'll grab the gcc-3.4 from chinstrap then.04:54
dokojbailey: yes please. but don't grab the new bugs introduced in the package ;)04:55
jbaileyErr>04:56
jbaileyI'm still waking up and am a bit hung over.  What do I need to do? =)04:56
dokojbailey: just grab the diff.gz.04:59
dokothe diff that you sent me didn't include the amd64 biarch support (only the i386)05:00
=== desrt [~desrt@dhcp-0-20-af-d2-7c-3.cpe.mountaincable.net] has joined #ubuntu-toolchain
jbaileydoko: Right.  So the amd64 will ftbfs until I do the matching changes there.08:45
jbaileyThat's no big deal, though08:45
lamontjbailey: I'm unleashing hppa's buildd with a glibc that you will hopefully supersede soon09:10
dokolamont: pleasse could you have a look at the openoffice.org build failure on i386?09:12
lamontdoko: thanks09:15
lamontfixed, 3 packages given back09:16
lamontdoko: you looked at isdnutils recently?09:20
lamontoh, nm09:20
jbaileylamont: Ubuntu?  Is there a new glibc?09:21
lamontjbailey: you're going to upload a new glibc to ubuntu shortly, yes?09:21
lamontso I dropped my local build into place (...ubuntu7hppa1) with confidence that ubuntu8 would arrive sometime in the next day or so... right?09:22
lamontand yes, ubunut09:22
lamontdebian is still playing roulette09:22
lamontand would you like me to file a bug against glibc/debian?09:23
jbaileyPlease.09:32
jbaileyYes, I have ubuntu8 ready, I'll drop that patch and respin it when I do my final verify builds.09:33
jbaileyI'm going to get back to doing the gcc-4.0 builds now for i386/amd6409:33
jbaileyHmm.  I wonder if elmo would consider nfs mounting chinstrap home dirs onto all the other directories.09:35
jbaileyIt's such a pain in the ass to move files between machines.09:35
dokolamont: it's still the empty xutils09:39
jbaileydoko: Hmm.  What's the best way to disable 64 bit mudflap only?  It doesn't look like you have it differentiated for 32 and 64 bit passes at all.09:49
jbaileyAnd I don't see how to set with_madflap := no for only onepass.09:49
jbaileyOh.09:49
jbaileyDuh09:49
jbaileyIn rules.d/binary-libmudflap.mk you mention with_lib64mudflap09:50
dokodebian/patches/i386-config-ml.dpatch: remove the mudflap line09:50
dokoor better: make a new patch i386-config-ml-nomf, we need the current one for debian09:52
jbaileyAh, doing with_lib64mudflap := no, doesn't add --diable-mudflap 09:54
jbaileyI had hoped it would.09:54
dokoyes, because this disables the normal build as well09:55
jbaileyRight.09:55
jbaileyBecase it's actual multilibs, not two build passes.09:56
jbaileyIf mudflap building in 64 bit mode on Debian right now then?09:56
dokoit does build, for getting saner testresults. it's not yet packaged09:57
jbaileyRight, but I'm curious then why it's not even building for me.09:57
=== jbailey actually looks at the error.
jbaileyI want to make sure that it's not some side effect of something I did wrong elsewher ein the biarch setup.09:58
dokoyep, not all the runtime libraries are setup to be correctly built as biarch, the C++ includes are one case ...10:00
jbaileySo should I make a complete copy of that config and only included it for Ubuntu?10:05
jbaileyLooking at the code, I don't see how this builds on Debian.10:05
jbaileyIt looks like I could possibly just take this line out of the i386-config-ml patch:10:05
jbailey+                       *"libmudflap" ) multidirs="${multidirs} ${x}" ;;10:05
dokoyes, correct10:08
dokoit builds on Debian (at least it did with glibc-2.3.2 and amd64-libs-dev)10:09
jbaileyHmm10:10
jbaileyThe header file that's being complained about is wrapped if #ifndef _MUDFLAP, and I wonder if the newer glibc causes that to not be defined.10:10
jbaileyBut that looks sufficiently minor.10:10
jbaileyOr might be some side effect of building this with gcc-3.410:10
dokoprobably the latter, why don't you use the just built compiler? build/gcc/xgcc -Bbuild/gcc/ ?10:21
jbaileyI'd have assumed that it would have10:21
jbaileyBut I know that occasioanlly things get confused.  I have /usr/bin/gcc symlinked to gcc-3.4 right now until I get this biarch gcc-4 built.10:22
jbaileyI'll try it without this patch once I have a working version.10:22
dokoor: make -C build maybe-all-target-libmudflap, but remove the libmudflap directory first10:22
jbaileylamont: BTW, did you test removing that patch on the other archs?11:12
jbaileyOh, I see.  it's hppa only.11:12
jbaileyEasy enough then. =)11:12

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!