• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
rnw159

Cross compiling: General Questions

6 posts in this topic

So I'm trying to cross compile a large project on Ubuntu x86 for ARM unix and windows x86. 

 

Questions:

 

For the ARM cross compile I have to compile all of the libraries it uses seperatly before using a toolchain to compile the whole project right? If not whats the proper procedure?

 

For the windows compile do I need to recompile all the libraries? Or will it be fine because its using the same cpu architecture?

 

What will a change in os mean for the work I have to do?

 

What will a change in cpu architecture mean?

 

What will a change in both mean?

 

Thank you for your help.

0

Share this post


Link to post
Share on other sites

For the ARM cross compile I have to compile all of the libraries it uses seperatly before using a toolchain to compile the whole project right? If not whats the proper procedure?

 

Well, no, you just need to use the ARM toolchain to build your stuff. This is basically the same as your ordinary compiler, but instead of using your system's libraries and building for your own processor architecture, it'll build for generic ARM libraries and an ARM processor. You won't be able to run the executable on your own machine, but it will work in an ARM emulator as well as a real ARM device (if done properly).

 

 

 


For the windows compile do I need to recompile all the libraries? Or will it be fine because its using the same cpu architecture?

 

Yes. Windows and Linux have different libraries and you must recompile. In fact Windows and Linux even have a different ABI for the x86_64 processor, so it's not even really the "same" processor architecture. So yes you will have to compile once for Linux, and once for Windows. In general trying to cut corners by compiling some code and not other code for a new target is bound to cause issues with binary compatibility and library references, so it's best to just recompile everything at once.

 

That said if you have already built independent parts of your code for a given OS + architecture, you don't need to recompile them again if nothing has changed. You can reuse them, just make sure you track them properly to make sure you are not linking to an outdated or incompatible version of your code,

 

 

 


What will a change in os mean for the work I have to do?

 

You'll need to:

1. get a cross-compilation toolchain for the new OS.

2. adapt your code to support the OS (moar #ifdef's or using cross-platform libraries)

3. run tests on one more OS

 

 

 


What will a change in cpu architecture mean?

 

You'll need to:

1. make sure your cross-compiler supports that processor architecture

2. if applicable, take advantage of that processor architecture in your code (if you're not doing inline assembly, you don't need to worry about this)

3. run tests on one more processor architecture

 

Note this depends on "how different" the new CPU architecture is. If you're just adding support for extra features of a processor you already support, you should be fine and there should not even be a need to recompile anything. But if you are supporting a whole new CPU with different instruction set and everything, then you must start again from scratch with that processor.

Edited by Bacterius
1

Share this post


Link to post
Share on other sites

Thanks for the info. Back to the ARM compile for a second: Say the program uses Boost, will I need to recompile Boost under ARM (or a toolchain)? Or will I be able to compile the whole project using the version of boost already compiled and used in the project? 

 

 

Thank you so much for the thorough response.

0

Share this post


Link to post
Share on other sites

Thanks for the info. Back to the ARM compile for a second: Say the program uses Boost, will I need to recompile Boost under ARM (or a toolchain)? Or will I be able to compile the whole project using the version of boost already compiled and used in the project?

 

In general, yes, every library you use must be compiled using the same toolchain as your main project, to be able to correctly resolve system calls, making sure it's using the right instruction set (you can't run x86 code on ARM) and other stuff. A cross-platform library/program doesn't mean a binary that can run everywhere, it means a library/program you can compile relatively effortlessly for most if not all operating systems and architectures.

 

If you try to link your project (built against ARM) against a library (built against your computer, say x86), what will happen is:

1. the cross-compiler will complain that it can't find the entry points of every single external function called by the library because it only has access to the system libraries of the operating system you are building for, which are obviously not compatible with your own (the ones you used to build the library) since they are for different architectures and hence different calling conventions, and so on (and possibly even different operating systems)

2. the cross-compiler will complain the library is corrupted or incompatible, because it's using x86 instructions instead of ARM instructions

 

A good way to think about this is that when you are using a cross-compiler, your own system becomes simply a tool to run the compiler. Nothing else is used and the result of the cross-compilation must not depend on what you used to compile your project (you might as well have compiled it on a toaster - it doesn't matter because when cross-compiling the only thing your system does is run the compiler).

Edited by Bacterius
0

Share this post


Link to post
Share on other sites

Well I have maybe 20 external libraries in this project. Is there any easy way to get already compiled libraries for other platforms? It takes ages to compile these libraries, and the ones that compile fast are always the hardest to use a cross compiler with.

0

Share this post


Link to post
Share on other sites

Well I have maybe 20 external libraries in this project. Is there any easy way to get already compiled libraries for other platforms? It takes ages to compile these libraries, and the ones that compile fast are always the hardest to use a cross compiler with.

 

Yes. In large popular libraries there are often release builds for many platforms, which should be compatible with your toolchain. Sometimes other users might have already built them and put them up for download somewhere. Though this is more popular in the Windows world - the Linux/Unix spirit is to compile the code yourself for your system, which as you probably noticed makes cross-compiling somewhat unintuitive, because those users are not usually exposed to the concept of compiling for other platforms, whereas other users (in particular Windows users) need to deal with coexisting 32-bit and 64-bit programs and libraries which are incompatible with one another, so they often have to ask themselves the question "which one do I need" which makes cross-compiling come more naturally, IMHO.

 

However if the library has never been built for ARM or other platform, no, your only option is to compile it yourself, unfortunately, since it needs to get compiled somehow to be used. But again, if the library is well-known and your target system/platform is not exotic, it's very likely that it has already been built by someone and perhaps even by the official maintainers of the library as part of their release process. And if not, there are usually tutorials on how to do so for a given library.

 

As for the question you are probably going to ask next - yes, some libraries were not designed to be cross-platform (e.g. using hundreds of platform-specific functions and containing non-portable code) and so it would be almost impossible to port them to ARM or whatever, in which case your only option is to find another, more portable library that does the same thing, unfortunately. This is, sadly, a reality, and makes otherwise portable programs need extra work to become truly cross-platform because a dependency is holding them back. Things have gotten better, though, and such libraries are rare.

 

I agree it's a pain when every library seemingly uses a different build method (e.g. this one uses CMake, the other autotools, that one has a funky Python installer, and so on) but in my experience cross-compiling is something that's tedious and error-prone to set up, but works wonderfully once everything's up and running... it would be much easier if everyone would agree on a standard way to write and compile portable libraries, but you know how that works..

 

standards.png

Edited by Bacterius
1

Share this post


Link to post
Share on other sites

Thanks for the answers, I somehow avoided learning this stuff in school. You've helped me out a lot with this work.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0