development packages and multilib

[Orcan Ogetbil]

On Tue, Apr 21, 2009 at 11:30 PM, Callum Lerwick wrote:
> On Tue, 2009-04-21 at 18:14 -0400, Orcan Ogetbil wrote:
>> This is only for preventing file conflicts between RPMs. Honestly, as
>> I said before, I really don't understand the need of keeping different
>> arch devel packages in the same system at the same time.
>
> Why would you need to avoid conflicts if you're *not* going to install
> them both at the same time?
>
>> Just remove one and install another. You can even write a simple
>> script to do this. Create a local repo if you are worried about the
>> time loss.
>
> Why would I want to run a root command that screws with my root
> filesystem as part of my edit-compile-test cycle?
>
> $ gcc -O2 -Wall -m32 hello.c -o hello
> $ file ./hello
> ./hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not
> stripped
> $ ./hello
> Hello world!
> $ gcc -O2 -Wall -m64 hello.c -o hello
> $ file ./hello
> ./hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not
> stripped
> $ ./hello
> Hello world!
> $ i686-pc-mingw32-gcc -O2 -Wall hello.c -o hello.exe
> $ file ./hello.exe
> ./hello.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit
> $ ./hello.exe
> Hello world!
> $ mipsel-uclibc-gcc -O2 -Wall hello.c -o hello
> $ file ./hello
> ./hello: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV),
> dynamically linked (uses shared libs), not stripped
> $ qemu-mipsel -L /opt/brcm/hndtools-mipsel-uclibc/ ./hello
> Hello world!
>
>
> Why must you insist on making my life more difficult than it already is?
> Why do we even bother having an -m32 flag in gcc if we're not going to
> use it?
>

Ah, those folks who feel the need of testing their program in all
archs after every other line of coding can use an interpreter based
language. It will be less pain for all parties.

Also, you can make the arch-independent xxxxx-config script smarter,
so that whenever you pass a magic flag it will redirect you to the
correct binary. If you don't pass the magic flag it will default to
`uname -i`. When I said, "

> If you are dying for keeping different arch devel packages in the same
> system, you can write your code accordingly.

", I meant such usage.

Orcan