Alan Hourihane wrote:
This is tricky, and I'm not sure what normal "configure" scripts do with multilib. I suspect it may mean building the package multiple times to get the required libraries rather than trying to fix the build to build them in a single pass. Here I mean using "CFLAGS=-mshort -m68000" etc, etc, etc. on each "configure" pass.
Yes, I think source packages should totally ignore the multilibs.We just have to configure/make them multiple times, the best way is probably simply by overriding the CC variable, for example CC="gcc -m68030 -mshort". This is not a lie, since different multilib settings means actually different and incompatible compilers. For example, for SpareMiNT, I would like to see a script which takes a source RPM as input, asks GCC for the list of available multilibs, run iteratively the rpm command with a CC override, so all the binary packages for executables will be built. For library -devel packages, that multilib loop should be put inside the rpm spec in order to provide all the multilib libraries in the unique -devel package.
Sure. But the main part here is the GCC patch. We should be enabling developers to do the maximum possibly with our platform. Once that's in place, it's the package maintainers responsibility or developer to choose on how they work.
That's really easy. GCC is probably one of the very rare GNU package aware of multilibs. Keith showed the config file recently. We just have to put what we want into that file, and it will automatically build libgcc and so on for all the defined multilibs.
If we can sort out the GCC part, the rest will follow :-)
GCC is not a problem at all. Will the rest follow ? -- Vincent Rivière