32 and 64 bit programs?

[arromdee]

I installed the 64 bit version of Mageia 5. Is it possible to compile and run a program as 32 bits? (dosbox-x only has dynamic x86 core implemented for 32 bits, it does not work with 64 bits.) There's a /usr/lib and /usr/lib64 directory for libraries and -m32 is a compiler flag for 32 bit, but how do the includes work? There's only one include directory.

[ozky]

Where you need dosbox-x we already have dosbox in repos it's working fine with 64bit ?.

[doktor5000]

Yes, it is possible to cross-compile a program.
And for the includes, /usr/include just contains source code which is for any architecture.

What is your actual problem, and what is the command you run and what error message do you get?

[arromdee]

And for the includes, /usr/include just contains source code which is for any architecture.

What happens when the header file for the 32 bit version doesn't match the one for the 64 bit version? Are we guaranteed that everything uses ifdefs and has the same header file, rather than using configure to generate a different header file for a 32 and 64 bit build, or otherwise having different headers between 32 and 64 bits?

What is your actual problem, and what is the command you run and what error message do you get?

No problem yet. I seek knowledge before doing things that might mess up my system irreversibly.

Where you need dosbox-x we already have dosbox in repos it's working fine with 64bit ?.

1) dosbox was last modified in 2010 unless you get the svn version (which I assume is not in the repo) and has a bunch of things missing (for instance, no integrated glide patch)

2) dosbox is very strict about not including fixes that don't directly fix a game

[arromdee]

I just tried installing 32 bit development files. Upon trying to install 32 bit libSDL after already having development files for 64 bit SDL installed), I get this error when installing one of the prerequisites:

1 installation transactions failed

There was a problem during the installation:

file /usr/include/ggi/system.h from install of libgii-devel-1.0.2-20.mga5.i586 conflicts with file from package lib64gii-devel-1.0.2-20.mga5.x86_64

It appears that the include files are not, after all, the same between 32 and 64 bit. Does this means it is impossible for me to compile a program as 32 bit if it needs such files?

[doktor5000]

Does this means it is impossible for me to compile a program as 32 bit if it needs such files?

No it just means you cannot have all 32bit and x86_64 -devel packages installed in parallel.

[arromdee]

Does this means it is impossible for me to compile a program as 32 bit if it needs such files?

No it just means you cannot have all 32bit and x86_64 -devel packages installed in parallel.

How is not being able to have the package installed, not the same as being impossible to compile? (Unless I keep uninstalling and reinstalling packages whenever I want to compile something?)

[doktor5000]

No it just means you cannot have all 32bit and x86_64 -devel packages installed in parallel.

How is not being able to have the package installed, not the same as being impossible to compile? (Unless I keep uninstalling and reinstalling packages whenever I want to compile something?)

You did not pay attention to what I wrote, especially for you I've added some emphasis.

You want to compile a 32bit program or compile something against 32bit -devel packages, then install those.
You already have the x86_64 -devel packages installed and get file conflicts during installation? Then you need to remove the conflicting x86_64 -devel packages first.

And previously you mentioned "dosbox-x only has dynamic x86 core implemented for 32 bits, it does not work with 64 bits."
So you could only compile it against 32bit -devel packages. So yes, if you then afterwards want to compile something against
the x86_64 packages which are required for dosbox-x you need to keep uninstalling and installing. But that is your choice.

[arromdee]

What did you mean when you previously said

And for the includes, /usr/include just contains source code which is for any architecture.

? If what you said was actually true, I shouldn't have to keep uninstalling and installing since the code in /usr/include would be for both architectures.

[doktor5000]

The devel packages do not only include header files, but also .so shared objects or also called libraries.
The libraries can be installed in parallel as they go either in /usr/lib or /usr/lib64 but the headers cannot as they go to /usr/include.
The headers might be split out into separate packages to avoid the conflicts but that is just too much work for us packagers and would result
in several thousands of addtitional subpackages to maintain and file lists to keep updated.

But feel free to disbelieve me.
I have answered your questions and told you how to solve the file conflict you posted, it's EOT for me at this point.

[arromdee]

You seem to have answered my questions in a contradictory way.

You can't say that headers are architecture-independent in one post, and then later on, say that headers can have conflicts between architectures.

[marja]

You seem to have answered my questions in a contradictory way.

I agree on "seem"

You can't say that headers are architecture-independent in one post, and then later on, say that headers can have conflicts between architectures.

His answer to your question :

There's a /usr/lib and /usr/lib64 directory for libraries and -m32 is a compiler flag for 32 bit, but how do the includes work? There's only one include directory.

was:

And for the includes, /usr/include just contains source code which is for any architecture.

It was an answer about which directory to use.

He did not say "/usr/include just contains source code which is always exactly the same for any architecture."

Maybe it isn't?