#ubuntu-toolchain 2006-04-03
<jbailey> doko: There?
<jbailey> doko: I got a few people to agree to the 'silence is assent' policy for patch renames in Debian.  I'll post to debian-glibc@l.d.o tongiht with the proposal.
<doko> jbailey: pong
#ubuntu-toolchain 2006-04-05
<jbailey> doko: Was that answer enough for your Xen stuff?
<doko> sure thanks!
<jbailey> Cool. =)
#ubuntu-toolchain 2007-04-03
<GyrosGeier> hi
<GyrosGeier> given the massive overlap in toolchain maintainers and the lack of a #debian-toolchain, I think it's a good thing to ask here
<GyrosGeier> I am building packages that provide wrappers around gcc that make it compile against uclibc
<GyrosGeier> for that to work, I need to create symlinks from e.g. /usr/lib/gcc/foo-linux-uclibc/4.1.2/cc1 to /usr/lib/gcc/foo-linux-gnu/4.1.2/cc1
<GyrosGeier> however gcc version is currently at 4.1.1-*
<GyrosGeier> and somewhere in the 4.1.1-* time, directory switched from .../4.1.1 to .../4.1.2
<GyrosGeier> since my symlinks only work if the directories do not change, I'm wondering how to form a dependency that will break as soon as gcc's tool directory changes
<GyrosGeier> and not much more often than that, ideally
<GyrosGeier> (specifically, I'd like to avoid an (= 4.1.1-12) dependency, for obvious reasons)
<GyrosGeier> any ideas?
<jb-home> doko: There?
<doko> jb-home: hey, back to your second baby? ;-P
<jb-home> Yeah. =)
<jb-home> I just noticed that gcc-3.4-hppa64 has a dependancy on libc6-dev.  I don't think it should.  It's not worth fixing that package or doing an upload for it, but might be nice to remove it for future gcc versions.
<doko> ok, will have a look
<jb-home> Thanks. =)
<jb-home> How's things? =)
<doko> see my toolchain mail; currently gcc-4.1 doesn't build anymore due to the new binutils
<doko> on powerpc and sparc
<jb-home> Joy.  My toolchain mail goes to my work account, I should probably change that.
<jb-home> Once I get some more hppa stuff building, I'll take a look at ppc.
#ubuntu-toolchain 2009-03-30
<munckfish> doko: how are you? Did you see the email I sent you about newlib-spu? I'm looking into the problem right now.
<munckfish> It's failing cause spu-ld can't find crt0.o which for some reason was missing from (I presume) the previous build of newlib-spu
<munckfish> I'm trying to see if I can get it to build using the old spu-newlib package from the old cell toolchain
<munckfish> is that a good approach? Then we could rebuild with gcc-4.3 stuff once it's up and running again
<doko> munckfish: no, it's just a missing dep, -2 did build. forgot to add this in -3
<doko> gdb: I don't know
<munckfish> ok cool. Which package is missing?
<munckfish> doko: gdb - shall I mail upstream?
<doko> newlib-spu
<doko> munckfish: check trunk first
<munckfish> but the previous newlib-spu doesn't have crt0.o in it? so if my understanding is correct that's a catch-22 right?
<munckfish> where is trunk?
<munckfish> ok I found the trunk, I'll try building that, but I doubt it'll work cause spu-gcc is failing because the last successful newlib-spu package is missing crt0.o
<munckfish> doko: I have to go now. I'll be around again tomorrow. cheers.
#ubuntu-toolchain 2009-03-31
<munckfish> Hi toolchain folks - is there anyone here who could provide some advice on fixing the newlib FTBS on powerpc?
<arthur-> munckfish: "See `config.log' for more details.
<arthur-> "
<munckfish> arthur-: I did
<munckfish> I'm raising a bug on it now
<arthur-> munckfish: and what does it say?
<munckfish> /usr/bin/spu-ld: crt1.o: No such file: No such file or directory
<munckfish> the big issue here is
<munckfish> AFAIKT newlib-spu is supposed to provide crt1.o itself
<munckfish> but the last built version of newlib didn't include it for some reason
<arthur-> munckfish: so this can be a missing library path
<munckfish> that error occurs when the configure script does a basic test of spu-gcc
<munckfish> yes it's missing
<munckfish> what do you think we should do?
<munckfish> the only way to get spu-gcc to work without this is to tell it not link in the default libc stuff (I can't remember the option)
<arthur-> munckfish: first, find -name "crt1.o"
<arthur-> munckfish: -nostdlib?
<munckfish> arthur-: do you think this file is being provided by a different package? Because it's not where it used to be
<munckfish> afaik it should be installed under the spu prefix ......
<arthur-> munckfish: did it use to be provided by gcc-spu or by newlib-spu ?
<munckfish> /usr/spu
<munckfish> arthur-: newlib-spu
<arthur-> munckfish: so it should be built in newlib-spu somewhere, if it's not, find why
<munckfish> arthur-: I check here: https://launchpad.net/ubuntu/+source/newlib/+publishinghistory
<munckfish> 1.17.0-0ubuntu3 - fails on ppc, 1.17.0-0ubuntu2 built but didn't include crt1.o, the versions before that included it
<arthur-> munckfish: crt1.o should be created *inside* newlib-spu, so this only means there were already the issue in -0ubuntu2
<arthur-> and this is what you have to fix
<munckfish> arthur-: ok. I will try to find out why it's not been built. If this package essentially depends on itself, and itself is currently broken, what would be the approach to getting it to build again?
<arthur-> and then drop the build-depends on newlib-spu
<arthur-> munckfish: as said, it should not depends on itself once fixed
<munckfish> arthur-: well I say it depends on itself but it's more like newlib ---> spu-gcc ---> newlib
<munckfish> Now I don't understand enough about this, but I'm guessing that building a version of libc (which newlib is) shouldn't need to link against libc
<munckfish> Do you think it's likely we could modify the standard configure check to use -nostdlib?
<munckfish> I don't have enough experience with configure to know whether that sort of thing is easy
<arthur-> munckfish: here is the point: version -Oubuntu2, for whatever reason, stoped to build crt1.o, so someone added a build-depends on newlib-spu to have it from version -0ubuntu1
<munckfish> aha, ok I see what your saying
<arthur-> munckfish: this worked well, but since it was not built in -0ubuntu2, -0ubuntu3 failed, and there is no such workaround possible anymore
<munckfish> doh!, I see Doko's comment now
<arthur-> munckfish: so you have to fix the issue that version -Oubuntu2 already have
<munckfish> arthur-: thanks! You pointed me in the right direction
<munckfish> I'll go hunt for the answer
<munckfish> :)
<arthur-> np
#ubuntu-toolchain 2016-04-07
<sig> I recall there used to be #toolchain or similar that was catch-all for GCC/shell scripting/linux whatever
#ubuntu-toolchain 2018-04-05
<lorddoskias> hello 
<lorddoskias> anyone from ubuntu working on the toolchain around?
