Problems compiling Gambas for ARM Linux

I am having some issues cross-compiling Gambas for ARM Linux, using the
OpenEmbedded toolchain. My build log is attached. It looks like Gambas'
build system is messing up the include paths in this case? Or is this
something wrong with OE specifically?

Thanks for any help.
--
Andrew Barr
andrew.james.barr@...

NOTE: make
make  all-recursive
make[1]: Entering directory `/media/usbdisk/oe/tmp/work/armv5te-angstrom-linux-gnueabi/gambas2-2.6.0-r0/gambas2-2.6.0'
Making all in main
make[2]: Entering directory `/media/usbdisk/oe/tmp/work/armv5te-angstrom-linux-gnueabi/gambas2-2.6.0-r0/gambas2-2.6.0/main'
make  all-recursive
make[3]: Entering directory `/media/usbdisk/oe/tmp/work/armv5te-angstrom-linux-gnueabi/gambas2-2.6.0-r0/gambas2-2.6.0/main'
Making all in libltdl
make[4]: Entering directory `/media/usbdisk/oe/tmp/work/armv5te-angstrom-linux-gnueabi/gambas2-2.6.0-r0/gambas2-2.6.0/main/libltdl'
make  all-am
make[5]: Entering directory `/media/usbdisk/oe/tmp/work/armv5te-angstrom-linux-gnueabi/gambas2-2.6.0-r0/gambas2-2.6.0/main/libltdl'
/bin/sh ./libtool --tag=CC --mode=compile ccache arm-angstrom-linux-gnueabi-gcc -march=armv5te -mtune=xscale -DHAVE_CONFIG_H -I. -I. -I.   -isystem/media/usbdisk/oe/tmp/staging/arm-angstrom-linux-gnueabi/include  -isystem/media/usbdisk/oe/tmp/staging/arm-angstrom-linux-gnueabi/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -c -o ltdl.lo ltdl.c
mkdir .libs
 ccache arm-angstrom-linux-gnueabi-gcc -march=armv5te -mtune=xscale -DHAVE_CONFIG_H -I. -I. -I. -isystem/media/usbdisk/oe/tmp/staging/arm-angstrom-linux-gnueabi/include -isystem/media/usbdisk/oe/tmp/staging/arm-angstrom-linux-gnueabi/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -c ltdl.c  -fPIC -DPIC -o .libs/ltdl.o
 ccache arm-angstrom-linux-gnueabi-gcc -march=armv5te -mtune=xscale -DHAVE_CONFIG_H -I. -I. -I. -isystem/media/usbdisk/oe/tmp/staging/arm-angstrom-linux-gnueabi/include -isystem/media/usbdisk/oe/tmp/staging/arm-angstrom-linux-gnueabi/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -c ltdl.c -o ltdl.o >/dev/null 2>&1
/bin/sh ./libtool --tag=CC --mode=link ccache arm-angstrom-linux-gnueabi-gcc -march=armv5te -mtune=xscale  -isystem/media/usbdisk/oe/tmp/staging/arm-angstrom-linux-gnueabi/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os  -L/media/usbdisk/oe/tmp/staging/arm-angstrom-linux-gnueabi/lib -Wl,-rpath-link,/media/usbdisk/oe/tmp/staging/arm-angstrom-linux-gnueabi/lib -Wl,-O1 -o libltdlc.la   ltdl.lo -ldl
arm-angstrom-linux-gnueabi-ar cru .libs/libltdlc.a .libs/ltdl.o
arm-angstrom-linux-gnueabi-ranlib .libs/libltdlc.a
creating libltdlc.la
(cd .libs && rm -f libltdlc.la && ln -s ../libltdlc.la libltdlc.la)
make[5]: Leaving directory `/media/usbdisk/oe/tmp/work/armv5te-angstrom-linux-gnueabi/gambas2-2.6.0-r0/gambas2-2.6.0/main/libltdl'
make[4]: Leaving directory `/media/usbdisk/oe/tmp/work/armv5te-angstrom-linux-gnueabi/gambas2-2.6.0-r0/gambas2-2.6.0/main/libltdl'
Making all in gbx
make[4]: Entering directory `/media/usbdisk/oe/tmp/work/armv5te-angstrom-linux-gnueabi/gambas2-2.6.0-r0/gambas2-2.6.0/main/gbx'
if /bin/sh ../libtool --tag=CC --mode=compile ccache ccache arm-angstrom-linux-gnueabi-gcc -march=armv5te -mtune=xscale -DHAVE_CONFIG_H -I. -I. -I.. -I../share    -I../libltdl  -I/usr/include/x86_64-linux-gnu/  -isystem/media/usbdisk/oe/tmp/staging/arm-angstrom-linux-gnueabi/include -DGBX_INFO -pipe -Wall -Wno-unused-value -fsigned-char -fvisibility=hidden -g -Os -O0  -MT gb_la-gbx_c_class.lo -MD -MP -MF ".deps/gb_la-gbx_c_class.Tpo" -c -o gb_la-gbx_c_class.lo `test -f 'gbx_c_class.c' || echo './'`gbx_c_class.c; \
        then mv -f ".deps/gb_la-gbx_c_class.Tpo" ".deps/gb_la-gbx_c_class.Plo"; else rm -f ".deps/gb_la-gbx_c_class.Tpo"; exit 1; fi
mkdir .libs
 ccache ccache arm-angstrom-linux-gnueabi-gcc -march=armv5te -mtune=xscale -DHAVE_CONFIG_H -I. -I. -I.. -I../share -I../libltdl -I/usr/include/x86_64-linux-gnu/ -isystem/media/usbdisk/oe/tmp/staging/arm-angstrom-linux-gnueabi/include -DGBX_INFO -pipe -Wall -Wno-unused-value -fsigned-char -fvisibility=hidden -g -Os -O0 -MT gb_la-gbx_c_class.lo -MD -MP -MF .deps/gb_la-gbx_c_class.Tpo -c gbx_c_class.c  -fPIC -DPIC -o .libs/gb_la-gbx_c_class.o
CROSS COMPILE Badness: /usr/include in INCLUDEPATH: /usr/include/x86_64-linux-gnu/
cc1: internal compiler error: in add_path, at c-incpath.c:362
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [gb_la-gbx_c_class.lo] Error 1
make[4]: Leaving directory `/media/usbdisk/oe/tmp/work/armv5te-angstrom-linux-gnueabi/gambas2-2.6.0-r0/gambas2-2.6.0/main/gbx'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/media/usbdisk/oe/tmp/work/armv5te-angstrom-linux-gnueabi/gambas2-2.6.0-r0/gambas2-2.6.0/main'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/media/usbdisk/oe/tmp/work/armv5te-angstrom-linux-gnueabi/gambas2-2.6.0-r0/gambas2-2.6.0/main'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/media/usbdisk/oe/tmp/work/armv5te-angstrom-linux-gnueabi/gambas2-2.6.0-r0/gambas2-2.6.0'
make: *** [all] Error 2
FATAL: oe_runmake failed

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Gambas-devel mailing list
Gambas-devel@...
https://lists.sourceforge.net/lists/listinfo/gambas-devel

[Benoit Minisini]

On jeudi 05 juin 2008, Andrew Barr wrote:
> I am having some issues cross-compiling Gambas for ARM Linux, using the
> OpenEmbedded toolchain. My build log is attached. It looks like Gambas'
> build system is messing up the include paths in this case? Or is this
> something wrong with OE specifically?
>
> Thanks for any help.

The error message seems clear: you have encountered a bug in gcc, and it asks
you to submit a bug report!

Anyway, it is strange that the compiler has a x86_64 include in its path when
compiling for arm. It is really a compiler bug or did you do something weird
in your cross-compile environment?

I can't tell you more, I've never made a cross-compile in my life...

Regards,

--
Benoit Minisini

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Gambas-devel mailing list
Gambas-devel@...
https://lists.sourceforge.net/lists/listinfo/gambas-devel

On Fri, 2008-06-06 at 12:33 +0200, Benoit Minisini wrote:
> The error message seems clear: you have encountered a bug in gcc, and it asks
> you to submit a bug report!

I did some further investigation, and this appears to be happening
because an x86_64 version of the software is available in the build
system, but the ARM version is not. I'm not entirely clear on what the
problem is but it does appear to be triggered by missing dependencies.

The internal compiler error message is because the toolchain is
specially patched with OpenEmbedded/Angstrom QA checks, one of which is
no /usr/include in includepaths. From what I understand of OE mailing
list messages, removing insane.bbclass (QA checks) from my build and
rebuilding the toolchain should eliminate the CROSS COMPILE badness
messages.

It is no matter, because I have a new problem. Working around the CC
badness messages by disabling components missing dependencies, I have
built a partial install of Gambas for ARM, but the install phase fails
when generating the component information files, because the build
system tries to run gbi2, which is an ARM Linux binary, on x86_64. I am
not sure how to fix this problem other than to use QEMU or some more
elegant solution like Scratchbox. I think that QEMU can be configured,
along with the binfmt_misc feature of the Linux kernel, to automatically
run when binaries for other CPUs are executed, so maybe that is worth
trying.

I don't think there's any problem with the Gambas build system at this
point, I am just writing this up in case someone else tries this.
Hopefully I will have a Gambas runtime for embedded Linux soon, because
I would like to be able to run my Gambas apps on my handheld
computer(s).

--
Andrew Barr
andrew.james.barr@...

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Gambas-devel mailing list
Gambas-devel@...
https://lists.sourceforge.net/lists/listinfo/gambas-devel

On Fri, 2008-06-06 at 17:07 -0400, Andrew Barr wrote:

> It is no matter, because I have a new problem. Working around the CC
> badness messages by disabling components missing dependencies, I have
> built a partial install of Gambas for ARM, but the install phase fails
> when generating the component information files, because the build
> system tries to run gbi2, which is an ARM Linux binary, on x86_64. I am
> not sure how to fix this problem other than to use QEMU or some more
> elegant solution like Scratchbox. I think that QEMU can be configured,
> along with the binfmt_misc feature of the Linux kernel, to automatically
> run when binaries for other CPUs are executed, so maybe that is worth
> trying.

Using the Scratchbox build system, which integrates QEMU for cases like
this, I have been able to successfully compile Gambas plus some
components for ARM Linux. However, now it is failing to run programs,
saying it cannot load the class file for "Balloon", which is in gb.form.
Now, the gb.qt component is disabled, as both my handheld devices use
GTK+, is it possible that this is the cause of the problem, or am I
dealing with some library loading error and need to dig deeper?

Thanks in advance.
--
Andrew Barr
andrew.james.barr@...

[phone] (Verizon Wireless)

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Gambas-devel mailing list
Gambas-devel@...
https://lists.sourceforge.net/lists/listinfo/gambas-devel

[Benoit Minisini]

On lundi 09 juin 2008, Andrew Barr wrote:

> On Fri, 2008-06-06 at 17:07 -0400, Andrew Barr wrote:
> > It is no matter, because I have a new problem. Working around the CC
> > badness messages by disabling components missing dependencies, I have
> > built a partial install of Gambas for ARM, but the install phase fails
> > when generating the component information files, because the build
> > system tries to run gbi2, which is an ARM Linux binary, on x86_64. I am
> > not sure how to fix this problem other than to use QEMU or some more
> > elegant solution like Scratchbox. I think that QEMU can be configured,
> > along with the binfmt_misc feature of the Linux kernel, to automatically
> > run when binaries for other CPUs are executed, so maybe that is worth
> > trying.
>
> Using the Scratchbox build system, which integrates QEMU for cases like
> this, I have been able to successfully compile Gambas plus some
> components for ARM Linux. However, now it is failing to run programs,
> saying it cannot load the class file for "Balloon", which is in gb.form.
> Now, the gb.qt component is disabled, as both my handheld devices use
> GTK+, is it possible that this is the cause of the problem, or am I
> dealing with some library loading error and need to dig deeper?
>
> Thanks in advance.

Did you check the output of "make" and "make install"? No warning or errors?

Is ARM a little endian or big endian CPU?

--
Benoit Minisini

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Gambas-devel mailing list
Gambas-devel@...
https://lists.sourceforge.net/lists/listinfo/gambas-devel

On Sat, 2008-06-14 at 00:06 +0200, Benoit Minisini wrote:
> Did you check the output of "make" and "make install"? No warning or errors?

No, as long as you use Scratchbox (which integrates QEMU and allows the
execution of ARM binaries during the compile and install process), there
are no problems during the build.

FWIW, Debian has an ARM EABI port (called "armel") and they appear to
have Gambas binaries, which I imagine are autobuilt by a buildd. Since
one of the advantages of the EABI ("Embedded ABI") is that all ARM
embedded binaries are compatible across Linux distributions, I decided
to try those. It still appears to have problems finding symbols in class
files, and I haven't had the chance to dig into the Gambas source code
and figure out if there are any symbols missing from the gb.gtk
component that might be causing this. I did notice that the gb.form
component, which is what holds "Balloon" (it also complained about
"Action" once), directly depends on gb.qt in the Debian armel build. The
devices in question use X11, so installing Qt 3.x/4.x on the device is
not impossible, just undesirable given storage and memory constraints.

So really, it's a question of if Gambas can be made, either at build
time or run time, not to depend on Qt at all. Mind you there is no use
for the IDE, which I know has to have Qt, on an embedded device.

I have not tested a non-GUI program, yet.

> Is ARM a little endian or big endian CPU?

It can be either but for the devices and distribution I am using it is
little endian.

--
Andrew Barr
andrew.james.barr@...

[phone] (Verizon Wireless)

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Gambas-devel mailing list
Gambas-devel@...
https://lists.sourceforge.net/lists/listinfo/gambas-devel

[Rob Kudla]

On Saturday 14 June 2008 00:42, Andrew Barr wrote:
> So really, it's a question of if Gambas can be made, either at
> build time or run time, not to depend on Qt at all. Mind you there
> is no use for the IDE, which I know has to have Qt, on an embedded
> device.

You can definitely install and run Gambas without Qt (at least up to
the last 2.x release I deployed on a server.)  You may even be able
to build it without Qt, though I've never tried (I usually build
packages on a development machine and deploy just the packages I want
on a target machine with the same distro and version.)

Rob

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Gambas-devel mailing list
Gambas-devel@...
https://lists.sourceforge.net/lists/listinfo/gambas-devel

[Benoit Minisini]

On samedi 14 juin 2008, Andrew Barr wrote:

> On Sat, 2008-06-14 at 00:06 +0200, Benoit Minisini wrote:
> > Did you check the output of "make" and "make install"? No warning or
> > errors?
>
> No, as long as you use Scratchbox (which integrates QEMU and allows the
> execution of ARM binaries during the compile and install process), there
> are no problems during the build.
>
> FWIW, Debian has an ARM EABI port (called "armel") and they appear to
> have Gambas binaries, which I imagine are autobuilt by a buildd. Since
> one of the advantages of the EABI ("Embedded ABI") is that all ARM
> embedded binaries are compatible across Linux distributions, I decided
> to try those. It still appears to have problems finding symbols in class
> files, and I haven't had the chance to dig into the Gambas source code
> and figure out if there are any symbols missing from the gb.gtk
> component that might be causing this. I did notice that the gb.form
> component, which is what holds "Balloon" (it also complained about
> "Action" once), directly depends on gb.qt in the Debian armel build. The
> devices in question use X11, so installing Qt 3.x/4.x on the device is
> not impossible, just undesirable given storage and memory constraints.
>
> So really, it's a question of if Gambas can be made, either at build
> time or run time, not to depend on Qt at all. Mind you there is no use
> for the IDE, which I know has to have Qt, on an embedded device.
>
> I have not tested a non-GUI program, yet.
>
> > Is ARM a little endian or big endian CPU?
>
> It can be either but for the devices and distribution I am using it is
> little endian.

gb.form does not depend on gb.qt, but on gb.gui, a component that chooses
between gb.qt or gb.gtk according to the current running desktop: gb.qt is
chosen if you are running KDE, gb.gtk in the other cases.

Regards,

--
Benoit Minisini

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Gambas-devel mailing list
Gambas-devel@...
https://lists.sourceforge.net/lists/listinfo/gambas-devel