Unable to export to Linux platform

[rafalcieslak]

Even though Godot works well under my Ubuntu Linux, I am not able to export games to Linux.

I have downloaded and installed the export templates, and exporting to any other platform works as desired.

However, when choosing "Linux X11" as deployment target, Godot claims that:

• No 32bit export templates found.
• Download and install export templates.

It appears to me that the export templates installed successfully, as files {linux_server_32,linux_server_64,linux_x11_64_debug,linux_x11_64_release} are present in ~/.godot/templates/, although there is indeed no file "linux_x11_32_release".

It may be worth noting that I am running the 64bit Linux version of Godot.

[yuri-karadzhov]

Actually there is no 32bit linux template (only server ones but that's another platform) so the problem is - it does not allow to import to 64bit system because of abscence of 32bit template

[amagnoni]

copy the release and debug templates, renaming 64 to 32!
almost every system is 64 bits. it does not matter much!

[yuri-karadzhov]

it's also possible to build binary manually as it described in manual. It's just woraround but not a solution of the problem.

[TiZ-HugLife]

"copy the release and debug templates, renaming 64 to 32!
almost every system is 64 bits. it does not matter much!"
Ew, yuck, no, no, no! That is absolutely not the right way to do it, and it's nasty to even think about. There are still some 32-bit Linux platforms out there, enough to where Steam started out only on 32-bit. We should either support 32-bit properly or not at all, not hack together files and make potential players think we support 32-bit when we don't.

[godotengine]

The machine I'm using to build all the templates runs Ubuntu 64 bits. The compiler can cross compile 32 binaries, but the libraries (OpenGL, Alsa for example) to link are not there so I'm unable to make 32 bits binaries. Do you guys know how to fix this?

I think the last resort is to grab the deb files from ubuntu 32 and copy the libraries by hand to some local dir for compiling, but that kind of sucks and could break easily If I update Ubuntu.

[rafalcieslak]

Some common tricks include preparing a 32-bit chroot environment, but I believe that the simplest and most reliable solution is to install a 32-bit system within a virtual machine and build godot there.

[yuri-karadzhov]

The main problem is - it should be able to build 64bit binary for Linux even if 32bit template is not avalibe. So it's definetely a bug.

[avarisclari]

Yeah, that's the issue I have. I should be able to export to 64 bit regardless of 32 existing.

[godotengine]

From what i've been reading, using the chroot environment is the safest bet, Iĺl give that a try the next days

[zenogears]

oh my...
I am compilled godot in Kubuntu and my architecture is x86. I can't use amd64.
And i think many of people use x86. Not only me 8) And i want support 32 bit computers as well.
So i think i need Export Templates for 32 bit too.
I think it is unjustly that Windows have templates for 32 bit, but Linux hav't
But Thanks for engine - it is really cool.

[borfast]

A bit off-topic but I just want to add another voice for supporting 32-bit Linux. It's completely false that "almost every system is 64 bits. it does not matter much!", contrarily to what @amagnoni said.

Indeed, nowadays pretty much every CPU sold supports 64-bit (as well as 32-bit) but that doesn't mean the operating system is 64-bit, and this is what matters.

Most people, if informed at all, will remain with 32-bit until the day eventually comes when they absolutely need to move to 64-bit, because there is no advantage whatsoever and you actually end up losing because programs will take up a little more RAM with 64-bit. 95% of computer users do not need 64-bit at all but unfortunately think they want it because it will give them some advantage. It will not, unless you actually need it for some complex operations that make use of the 64-bit pointers, but if you do need it, you'll know you need it, and most people don't even have a clue about what a pointer or CPU register is, let alone knowing whether they need 64-bit operating systems. Rule of thumb: if you don't know you need it, you don't.

So please, do support 32-bit Linux, both for the editor and for exporting games. There's every reason to do it and no reason not to.

[godotengine]

Oh sorry about it, when I get back to the office tomorrow i'll see about
creating a chroot for compiling 32 bits

On Thu, Feb 13, 2014 at 9:11 AM, Raúl Pedro Santos <notifications@github.com

wrote:

A bit off-topic but I just want to add another voice for supporting 32-bit
Linux. It's completely false that "almost every system is 64 bits. it does
not matter much!"

Indeed, nowadays pretty much every CPU sold supports 64-bit (as well as
32-bit) but that doesn't mean the operating system is 64-bit, and this
is what matters.

Most people, if informed at all, will remain with 32-bit until the day
eventually comes when they absolutely need to move to 64-bit, because there
is no advantage whatsoever (unless you do complex operations that make use
of the 64-bit pointers, but if you do need it, you'll know you need it) and
you actually end up losing because programs will take up a little more RAM
with 64-bit.

So please, do support 32-bit Linux, both for the editor and for exporting
games. There's every reason to do it and no reason not to.

Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-34972571
.

OkamStudio

[borfast]

@okamstudio, no need to apologize, I think. We should all thank you for releasing the engine as open source - thank you! - and try to contribute to make it the best it can be (which is what I intended with my comment about 32-bit support above).

Thanks again!

[TiZ-HugLife]

"no advantage whatsoever"
How about the ability to use more than 4GB of RAM and extra architectural features (there aren't a lot, but they are there)? No need to use such hyperbole here, there are definitely advantages to using it.

[borfast]

@TiZ-EX1, I knew someone would eventually mention the 4GB thing, I should have "pre-answered" it in my previous comment.

You can use more than 4GB of RAM in 32-bit Linux (and Windows and OS X, and Solaris, And FreeBSD...), using Physical Address Extensions. Some modern distributions even enable it by default, so you don't even need to do anything. If it's not enabled, just use your distribution's package manager to install the package and away you go. There is no point in wasting RAM because of this.

What are the extra architectural features of 64-bit operating systems that regular users (and even developers) will take advantage of? (it's a genuine question; there may be things I am unaware of)

[TiZ-HugLife]

I forgot about PAE, gonna be frank about that. Regular users will not use the extra architectural features. The compilers that target the architecture do. So code compiled for x86_64 is faster than that compiled for i386. I don't know exactly how much faster, though.

[TiZ-HugLife]

Sorry, realized I didn't actually answer the question. Here's a summary of it: http://en.wikipedia.org/wiki/X86_64#Architectural_features

[reduz]

jeez guys, wait until tomorrow please! :) there's no 32 bits because Ubuntu
didn't ship a proper cross compiler, not because it's obsolete

On Thu, Feb 13, 2014 at 1:44 PM, TiZ-EX1 notifications@github.com wrote:

Sorry, realized I didn't actually answer the question. Here's a summary of
it: http://en.wikipedia.org/wiki/X86_64#Architectural_features

Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-34997932
.

[borfast]

@TiZ-EX1, but that's the thing: the majority of programs will not be any faster in 64-bit than they are on 32-bit because most of the architectural changes are meant for taking advantage of the increased capacity in addressing, which only very specific software takes advantage of with serious gains in performance. Multimedia software (video players, encoders, etc), scientific calculations software, maybe some graphics software will take advantage of it, but the rest is pretty much the same.

You may see a slight increase in speed if they take advantage of the extra registers (which, as you said, depends on the compiler, not the developer), but that is minimal and in my opinion doesn't justify having your software take up much more space in RAM.

But I ended up hijacking this thread, so I apologize and I'll shut up now :)

[amagnoni]

64 or 32 its just a matter of choice! there are people that still uses 16 bit computer or 16 bit systems!
so what?
godot is supported for 32 bit too... not in a binary, but is!
for now you have to compile yourself!
for users of 16 bit, you need to upgrade!

[xxblx]

Does it possible to compile build template (target) manually?
I successfully compiled Godot on Mageia 4 32-bit. But how I can to compile standalone linux-x11 32-bit template?

p.s. yep, I know that 64-bit is a future. but right 32-bit still has too big part of desktops.
p.p.s it's prefer for me to use Linux 32-bit PAE while I have 4 Gb RAM

[reduz]

yes:

debug template:

scons bin/godot target=release_debug tools=no

release template

scons bin/godot target=release tools=no

copy to ~/.coding/godot/templates

On Sat, Feb 15, 2014 at 11:24 PM, Oleg notifications@github.com wrote:

Does it possible to compile build template (target) manually?
I successfully compiled Godot on Mageia 4 32-bit. But how I can to compile
standalone linux-x11 32-bit template?

p.s. yep, I know that 64-bit is a future. but right 32-bit still has too
big part of desktops.
p.p.s it's prefer for me to use Linux 32-bit PAE while I have 4 Gb RAM

Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-35175321
.

[reduz]

uh and rename previously to the proper file name

On Sat, Feb 15, 2014 at 11:29 PM, Juan Linietsky reduzio@gmail.com wrote:

yes:

debug template:

scons bin/godot target=release_debug tools=no

release template

scons bin/godot target=release tools=no

copy to ~/.coding/godot/templates

On Sat, Feb 15, 2014 at 11:24 PM, Oleg notifications@github.com wrote:

Does it possible to compile build template (target) manually?
I successfully compiled Godot on Mageia 4 32-bit. But how I can to
compile standalone linux-x11 32-bit template?

p.s. yep, I know that 64-bit is a future. but right 32-bit still has too
big part of desktops.
p.p.s it's prefer for me to use Linux 32-bit PAE while I have 4 Gb RAM

Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-35175321
.

[xxblx]

@reduz , thanks!

[punto-]

actually

scons bin/godot_rel target=release tools=no

for the release binary I think

On Sun, Feb 16, 2014 at 12:31 AM, reduz notifications@github.com wrote:

uh and rename previously to the proper file name

On Sat, Feb 15, 2014 at 11:29 PM, Juan Linietsky reduzio@gmail.com
wrote:

yes:

debug template:

scons bin/godot target=release_debug tools=no

release template

scons bin/godot target=release tools=no

copy to ~/.coding/godot/templates

On Sat, Feb 15, 2014 at 11:24 PM, Oleg notifications@github.com wrote:

Does it possible to compile build template (target) manually?
I successfully compiled Godot on Mageia 4 32-bit. But how I can to
compile standalone linux-x11 32-bit template?

p.s. yep, I know that 64-bit is a future. but right 32-bit still has too
big part of desktops.
p.p.s it's prefer for me to use Linux 32-bit PAE while I have 4 Gb RAM

Reply to this email directly or view it on GitHub<
https://github.com/okamstudio/godot/issues/8#issuecomment-35175321>
.

Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-35175423
.

[boberfly]

Hi,

If you want cross-compiling with some generic defaults/compilers for 32/64-bit, may I suggest https://github.com/ValveSoftware/steam-runtime which sets i386 and amd64 chroot environments? You can use it purely to have sane/generic libs, libc, etc. which should work on any modern distros and just ignore the steam-specific library stuff if you don't want it.

[adolson]

this should probably be closed.