public inbox for crossgcc@sourceware.org
 help / color / mirror / Atom feed
From: "Diez B. Roggisch" <deets@web.de>
To: crossgcc@sourceware.org
Subject: crosstools, sysroolts and raspberries
Date: Fri, 25 Mar 2016 17:59:00 -0000	[thread overview]
Message-ID: <B8964C9C-3E80-423B-A867-3D38301B6BF2@web.de> (raw)

[-- Attachment #1: Type: text/plain, Size: 2554 bytes --]

Hey,

I’ve searched the internet high and low - but nowhere I found answers for my current problem of getting a proper sysroot for my raspberry PI2. I’ll try and outline my problem and current state of affairs as good as possible.

I run an ubuntu mate on a RPi model 2. After a while, I’m tired of compiling on the device, as probably most people who care about cross-compilation.

My host-system is a lubuntu trusty (actually running in a VM on my mac, but I guess that doesn’t matter), 64 bit.

So I downloaded crosstools-NG latest version (1.22.0), built it, picked armv7-rpi2-linux-gnueabihf sample, and built the toolchain.

It works. I can compile little hello-world programs, they run, hurray.

However, I of course want to use a lot of libraries - e.g. OpenCV, boost etc - and this is where my problems start.

I decided to use rsync to create a mirror of the installed dev and binary packages. I call that RPIROOT.

Now I can use -I, -L and -l options to compile & build against these libraries, and at least for the small toyish examples, that works just fine.

But my *dream* goal is to *not* do that, but instead use the —sysroot-option of the crosscompiler, point it to RPIROOT, and then just compile & link.

The primary reason for this is that I want to use standard built system tools like cmake, and I prefer using them with a CMAKE_TOOLCHAIN_FILE instead of creating my own built scripts/systems for each piec of library or executable that I want to use or create. I also would like to prevent to bootstrap all the libraries I use, especially since this would probably mean I need to install these on my PI as well.

And this is where the confusion starts. The ubuntu mate structures libraries differently than the sysroot that is part of the crosscompile chain. It puts e.g. cdefs.h not under /usr/include/sys/, but /usr/include/arm-linux-gnueabihf/sys. The same goes for libraries - they (some) are under /usr/lib/arm-…/ instead directly under /usr/lib, as in my XX-sysroot.

So the questions I have is:

 - is it even feasible to achieve what I want - a system where I use binaries pre-built? Or will I run into (subtle, runtimey) problems with e.g. the ABI, that I didn’t detect with my simple compilations so far?
 - if it *is* feasible, how do I teach my toolchain to use the same directory layout?
 - if it is *not* feasible, do I have to bootstrap all libraries, and is there a chance of doing that without having to fiddle with their buildsystems?

Thanks for listening,

Diez


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

             reply	other threads:[~2016-03-25 17:59 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-25 17:59 Diez B. Roggisch [this message]
2016-04-02  9:27 ` Waldemar Brodkorb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B8964C9C-3E80-423B-A867-3D38301B6BF2@web.de \
    --to=deets@web.de \
    --cc=crossgcc@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).