On Sun, 2012-07-22 at 13:47 -0700, shawn wrote: > On Sun, 2012-07-22 at 21:45 +0200, Guillem Jover wrote: > > No, not really. The main problem is that there's cases where there's > > no obvious 1:1 mapping, take i386/x32/amd64 or arm/armel/armhf/arm64, > > or mips where there's three ABIs, etc. And I don't think this is > > generally useful anyway, less so now with multiarch when multilib > > packages will be disappearing. I guess I already have to rework the calls into dpkg-architecture to work with this. I wasn't thinking about these cases. And since this is, well---a hack until much-arch takes over (does this really make sense to use full cross-compilers instead of multilib?) it would be OK to hard code some of this logic into the gcc-default/multilib defaults packages so that we can make it work now with the same api that the cross-compilers will provide--making the transition in the future easier.
Again, not sure which package should provide binutils symlinks. Maybe a new binutils-multilib package? This is a problem all the cross-compiler stuff is going to have to address as well. not that much stuff, but as its in the path maybe better to avoid polluting with stuff like putting it in the binutils package, and similar. > > > > > I would be using this for a patch making dpkg cross-building work with > > > gcc's multilib in gcc-defaults package. > > Where is this logic that i can tap into for creating these symlinks if > not in dpkg? > > > > thanks, > > guillem > > -- -Shawn Landden -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/1342990728.5910.199.camel@shawn-ssd
