On Thu, Dec 22, 2016 at 4:49 PM, Hector Oron wrote:

Hello,

2016-12-22 10:40 GMT+01:00 Roger Oberholtzer :

...

I also install from OBS the various libraries needed for the Windows cross compile. They are nicely put in /usr/i686-w64-mingw32/sys-root/mingw or /usr/x86_64-w64-mingw32/sys-root/mingw. They are not installed in the Linux /usr/bin/ or /usr/lib/ trees.

Would it matter if host tools install in host paths? I think it would be fine to also be installer in /usr/bin, /usr/lib.

I just need to make sure that /usr/bin/gcc and all are not replaced so they run the ARM version. In my makefiles, when doing a cross compile for Windows, I define the tools. gcc is, for example, /usr/bin/i686-w64-mingw32-gcc or /usr/bin/x86_64-w64-mingw32-gcc. These cross-compilers do not replace /usr/bin/gcc,

...

Unfortunately, I am guessing this would not be the case for ARM packages (e.g., libjpeg8-8.1.2-40.2.aarch64 and libjpeg8-devel-8.1.2-40.2.aarch64). They would be installed in the /usr/bin/ or /usr/lib/ trees, as that's where they are expected to be. Which is perhaps not what I want on a cross-compiling system

Install in a sysroot (directory for cross building purpose)? https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html

Those are the compiler and such options. That is no problem. My concern is when zypper/rpm install ARM stuff that it will put it in /usr, and replace the files for the host system. This is not good. I need the host files for 'normal' functioning and compiling, and the ARM ones off somewhere for cross-compiling. Exactly as is dons for the Windows things created in OBS. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On Mon, Dec 26, 2016 at 11:46 PM, Robert Munteanu wrote:

Hi,

On Thu, Dec 22, 2016 at 11:40 AM, Roger Oberholtzer wrote:

...

I am currently building software for a Raspberry using a Raspberry as the build computer. It works surprisingly well. Nonetheless, I am considering setting up doing cross compiling on an intel x86 (non ARM) computer. I guess installing cross compilers and such tools from OBS is okay. I already do this for doing Windows (32- and 64-bit) cross compiling.

Maybe the wrong question to ask, but have you considered qemu?

The problem, I think, is that I want to have the local system files in place (x86), as well as the ARM files. I think this may work for the cross compiler itself. But everything else for ARM is installed in the same place as the host files. I just wondered if someone had figured out a way to get the two to coexist. I am guessing that building for ARM is best done on an ARM device and not cross-compiled on a different host. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi Roger, On 02.01.2017 08:51, Roger Oberholtzer wrote:

The problem, I think, is that I want to have the local system files in place (x86), as well as the ARM files. I think this may work for the cross compiler itself. But everything else for ARM is installed in the same place as the host files. I just wondered if someone had figured out a way to get the two to coexist. I am guessing that building for ARM is best done on an ARM device and not cross-compiled on a different host.

If you want to cross-compile easily, use a distribution that's designed to do so -- I can heartily recommend openembedded / The Yocto Project. While it is possible to do a ARM sysroot installation and then use a cross-compiler with --sysroot= ..., it is painful (on openSUSE) and the number of possible mistakes to make is huge (and many of them are subtle, even more the problems you'll run into because of this subtle mistakes), so I would not recommend this to you, especially if you have to ask here how to do it ;-) QEMU emulated build is just damn slow, you are most likely better off just building natively on an raspberry pi 3. Best regards and good luck -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 02.01.2017 10:43, Roger Oberholtzer wrote:

On Mon, Jan 2, 2017 at 10:00 AM, Stefan Seyfried wrote:

...

If you want to cross-compile easily, use a distribution that's designed to do so -- I can heartily recommend openembedded / The Yocto Project.

I looked at this. But having all the packages available as RPMS managed by zypper is a handy thing.

Which is absolutely possible with The Yocto Project: zypper as package management, rpm as package format. I personally use opkg, but just because I'm using it on embedded platforms where space matters. And the killerfeature of openembedded for me: you can easily build a reloacatable SDK which allows for easy and painless crosscompilation, targeted for your exact target configuration.

I have ideas how to do it. I already do this type of thing with a number of other pieces of hardware. What I was exploring was if there was something I had missed for ARM and openSUSE. Like maybe there was a build like the Windows build that puts everything in a separate tree and all packages are noarch. One never knows what one may find somewhere on OBS.

Basically you'd need to do some kinde of chroot'ed install of an ARM root and use that as --sysroot for a suitable cross-compiler (if you find one).

I suspect I will go the real hardware routs and just keep a Raspberry PI 3 on the local network. It is already working fine.

Probably the easiest / most reliable way to do this. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi Andreas, Am 02.01.2017 um 17:11 schrieb Andreas Färber:

Hi Stefan,

Am 02.01.2017 um 10:53 schrieb Stefan Seyfried:

...

On 02.01.2017 10:43, Roger Oberholtzer wrote:

...

On Mon, Jan 2, 2017 at 10:00 AM, Stefan Seyfried wrote:

...

If you want to cross-compile easily, use a distribution that's designed to do so -- I can heartily recommend openembedded / The Yocto Project.

Let's be very clear that Yocto is _not_ a distribution but a toolkit for building your own distribution.

That's technically true, however, for all practical uses this distinction does not matter too much. It's like referring to gentoo as "_not_ a distribution but a toolset".

Which we should not be advertising on an opensuse-* mailinglist, as all benefits of our distro that users may rely on then vanish.

I'll comment on this in the next (similar) paragraph.

...

And the killerfeature of openembedded for me: you can easily build a reloacatable SDK which allows for easy and painless crosscompilation, targeted for your exact target configuration.

Please remember the original question, cross-compiling userspace software (for openSUSE).

Obviously I'm reading the original question in a different way than you do. openSUSE was not really mentioned.

Advising people against using openSUSE is not a solution to that question and highly questionable on an openSUSE mailing list!

Even though this is an openSUSE mailing list, I'm not going to suggest or even advocate that people use inferior tools, just because they happen to be delivered with openSUSE. I'm almost always advising people to use the best available tools for the given job. I'm advising debian users to run a SUSE VM / container if they want to package using the OBS / osc, even though there are osc packages for debian available. Why? Because it's the best thing to get the job done. The only time i'm sometimes advising to use inferior tools is when (IMHO) the inferior tool is e.g. much easier to use. And exactly the same I'm doing here. I'm advising to use an openembedded-built SDK for cross compiling because it is the most simple to use tool if you want to get the job (cross-compiling your software to a binary you can test on the target quickly) done.

I will also add that I published a paper on why openSUSE can be a better option for not too constrained embedded systems compared to Yocto or BuildRoot. They may seem more convenient at first, but they are either insecure if done lazily or quite work-intensive if done responsibly.

(Side note: quite often I get security fixes much faster from the Yocto project than from openSUSE. I could also publish a paper on that.) This is not about running the code later. Once the development is done, and the code is working, it can be built for openSUSE using the OBS easily and run in an openSUSE environment. But to develop the stuff, cross-compiling etc. is a major PITA on openSUSE compared to using an openembedded-built SDK. Been there, done that for a long time. I even maintained cross-compilers for PPC and ARM in my OBS home project. Finally took the (quite frightening) hurdle to start using OE/Yocto and never looked back. And don't get me wrong: this is not because openSUSE is technically inferior (it isn't), but because the scope of the projects is totally different. The SDK is a core feature of OE. Of course it would be possible to build a cross SDK for openSUSE, but it is a lot of work. Given there is a near perfect solution for developers, I personally just use the OE SDK instead of spending valuable time on reinventing the wheel, considering that it is a very special wheel used by only very few people.

So cross-compiling is possible theoretically, but ...

...a major PITA, unless you use the proper tools.

...

Probably the easiest / most reliable way to do this.

Native or qemu-linux-user are the two build options we recommend,

Now if you develop slightly larger pieces of software, qemu-linux-user is not really an option (simply because it is very slow and time does matter) and native is slightly faster (if you have at least a Raspberry pi 3 class machine), but given that you can get lots of Intel x64 build power dirt cheap with many gigabytes of RAM and blazing fast storage, I'd go for cross compiling.

cross-compiling is mainly used for kernels.

Ever asked yourself why kernels are not compiled with qemu-linux-user? Cross-compiling kernels is pretty trivial though, the kernel is pretty self contained so you have very little problems with host->target contamination, no pkg-config search path confusion, include path problems, you name it. Try to cross-compile a large C++ project, or cross-build some python bindings if you want to have "Fun". -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On Mon, Jan 2, 2017 at 11:27 PM, Josua Mayer wrote:

On the other hand, cross-compiling stuff on any distro that I am familiar with has usually been easy. The only case when I struggle is when there is a complex build-system involved with hacked-together scripts not aware of cross-compiling. There are many out there, but many others do just fine!

On openSUSE, we use good old GNU make to build for openSUSE, Windows, as well as various TMS DSP, PPC, Intel MCS51 and ARM 920 based boards. I was just hoping to get the Raspberry into all this. Our makefiles work on openSUSE on the Raspberry. I was just hoping to get them to run on our build system as all the other do. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On Tue, Jan 3, 2017 at 1:23 PM, Josua Mayer wrote:

Am 03.01.2017 um 09:08 schrieb Roger Oberholtzer:

...

On Mon, Jan 2, 2017 at 11:27 PM, Josua Mayer wrote:

...

On the other hand, cross-compiling stuff on any distro that I am familiar with has usually been easy. The only case when I struggle is when there is a complex build-system involved with hacked-together scripts not aware of cross-compiling. There are many out there, but many others do just fine! On openSUSE, we use good old GNU make to build for openSUSE, Windows, as well as various TMS DSP, PPC, Intel MCS51 and ARM 920 based boards. I was just hoping to get the Raspberry into all this. Our makefiles work on openSUSE on the Raspberry. I was just hoping to get them to run on our build system as all the other do.

I'd say if you can cross-compile for mingw, you can cross-compile for arm. There should be no difference in complexity. The cross-compilers are even in the default repos now, i.e. cross-armv7hl-gcc6.

The compiler is not the issue. It is the various libraries that an application may use. Unlike the windows libraries, which are placed off in some directory (the RPMs are so designed), the ARM ones are, of course, placed in the regular host location. So, for example, having the x86 libjpeg.so and ARM libjpeg.so files installed at the same time is not possible, unless you play with chroot or some other way to have the ARM things installed out of the way. I fear that it is too easy (for me at least) to make a mistake with this approach. It would be great if one could treat everything from a given repository in some way as a permanent setting. Like placing all aarch64 items in some tree other than /. And restricting these RPMs to only being able to write in that tree. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 03.01.2017 14:59, Andreas Färber wrote:

Am 02.01.2017 um 20:49 schrieb Stefan Seyfried:

...

Am 02.01.2017 um 17:11 schrieb Andreas Färber:

...

cross-compiling is mainly used for kernels.

Ever asked yourself why kernels are not compiled with qemu-linux-user?

armv6hl does use qemu-linux-user, including the kernel. Certainly it's not the fastest, but neither is native ARM11, and the amount of RAM on a Raspberry Pi 1 is inferior compared to x86_64 servers.

So you also agree that cross-compiling on x86_64 is beneficial for such targets, especially for developers who have many edit-compile-test cycles to run. And for that purpose, the OE SDK is one of the best tools available IMNSVHO. Additional bonus: you build it once and every developer can deploy it on his preferred Linux distribution, where he has all the tools (editors, VCS GUI frontends, ...) he likes best. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

The thread, which may have reached EOL, has lost it's way. I have been asking more about the general setup for cross-compiling more than about the GNU SDK. As I intend to deploy the Raspberry image as openSUSE, I am most interested in that environment. If I just want to test that the code compiles, I already compile for x86 openSUSE (12.3, 13.1, 42.2, Tumbleweed) and Windows (32- and 64-bit cross-compile with mingw). And as lots of the code is related to hardware access, testing will have to happen on a real device. The benefit of cross-compiling for ARM is outweighed by the chance of error maintaining an ARM install in parallel with the x86 install. I have my answer: compile on a Raspberry. It has the source mounted via NFS and the results are available immediately for packaging on the build server. Our make system allows parallel concurrent distributed builds for multiple architectures. The Raspberry device will be just another one. If I want to get fancy, all I lack on the Raspberry is subversion. But since the sources are shared over NFS, that is not a real issue. I just check in any Raspberry related changes from the x86 host. Thanks for the discussion! -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org