On 2016-06-09, Jonathan Wakely <jwakely@xxxxxxxxxxxxxxxxx> wrote:
> On 09/06/16 08:02 +0000, Petr Pisar wrote:
>>On 2016-06-08, Jonathan Wakely <jwakely@xxxxxxxxxxxxxxxxx> wrote:
>>> Think about it: you can't build 32-bit software **at all** unless you
>>> install glibc-devel.i686, not even just "int main() { }" with no
>>> headers at all.
>>>
>>That's because gcc.x86_64 accepts -m32 but cannot produce 32-bit
>>executable without the i686 toolchain packages. It sounds like broken
>>dependencies.
>
> The alternative would be for gcc.x86_64 to unconditionally install the
> 32-bit packages, even though most users will not use -m32 and so won't
> need them. Another alternative would be to build gcc with
> --disable-multilib so you can't use -m32, which would be annoying and
> inconvenient for users.
>
> What you call broken is a pragmatic engineering decision.
>
Some distributions insists on calling compiler by full quadruplet name
(x86_64-redhat-linux-gcc) when building packages. It's pitty we cannot
separate the target support, label it properly on RPM level and make it
subject of automatic dependency resolution.
I accept your resolution that it will not happen.
>>> This is independent of foobar-devel.
>>>
>>But with foobar-devel you would get full user experience in contrast
>>to a source code out of the repository. That would make distribution
>>easier to use.
>
> And what if you just want to build "int main() { }" with -m32? Why
> should building 32-bit software work out-of-the-box when using
> additional libraries from a -devel package, but not otherwise?
>
Because you install -devel package not to build "int main() { }". You
install it to use the -devel package files that are unusable without
included header files. I'm not after compiler. I'm after standard
library header files. But we where already here.
>>Ok. Let's have a broken distribution.
>
> You're being rather melodramatic.
>
Yes. It's disappoing when everybody blames someone else why a package is
not multilib safe.
>>Then people will ask what to depend on when including toolchain headers.
>>The guidelines should answer it like: Depend on nothing, this
>>dependency is left undeclared intentionally because a user is supposed
>>to install a toolchain of his choice manually.
>
> That's what the draft now says:
>
> https://fedoraproject.org/wiki/C_and_C%2B%2B_v2
Great. Thank you for all the explanations.
-- Petr
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
