Hi there and happy new year (:
I still have the issue to not be able to pass arguments to qemu (*)
Unfortunatly when putting those into SBOX_CPUTRANSPARENCY_METHOD, emulation
doesn't work anymore.
Any ideas how to fix that?
Thx,
Harry
PS: latest git of SB2
(*)(I have trouble compiling gtk
...ok, seems that -m 512 adding to qemu-arm helped...
My question is: where to put emulator options in Scratchbox2?
I tried to put them into the transparency variable export, but this causes
problems in sb2, when running arm progs
Harry
___
Scratchbox-
Hi!
I am trying to compile GTK using Scratchbox2, however, this time I guess this
problem is not related to the Scratchbox version:
During compilation, qemu bails out with a segmentation fault:
---
gcc -DG_DISABLE_DEPRECATED -g -O2 -Wall -o .libs/test-gdk-pix
uhm, nevermind, my fault...LOL, before installing into package dirs, maybe I
should first install into the root-fs so the lib is available (;
Sorry folks...so far, SB2 doing a great job!
Harry
___
Scratchbox-users mailing list
Scratchbox-users@lists.sc
Hey!
So far, building nearly everything using SB2 was basically a piece of cake,
and worked well (besides maybe speed, but still better than compiling
natively on my PDA *g*)...
Trying to build glib however introduced some problems: (besides the fact that
the threading test program built by ./
Hi there!
Still no luck with fixing my problems inside SB2 ...
gcc doesn't find include files in $HOME/root-fs/usr/include
SBOX_TARGET_ROOT is set correctly, gcc --help shows --sysroot option
when copying the header file to the include dir of the toolchain, it is found
Any hints how I can fix
> That's the right way to go about, anything that supports cross-compilation
> natively, should be built that way. I think sb2 is pretty good at solving
> the regular autotools package, anything totally exotic is likely to not
> work and I don't want to take the design decisions to make sb2 bulletp
> It seems sb2 has gotten a little slow ;)
> I guess the busybox buildsystem is hitting the path mapping code pretty
> hard. Will have to look at this more later.
well, I actually guess that getting things like busybox to work inside sb2
isn't that important since it is designed to cross compile..
hm, I updated the git source and rebuilt it...
Intersting:
* inside SB2, building busybox:
"make install prefix=/home/loonatix/BB"
takes about 40 secs before actual visbily proceeding (now I am not sure if it
really hung before the update or if I was just too unpatient, sorry!)
However, there
> This has now been dealt with in the emulation mode, so doing
> "sb2 -e make install" has access to $HOME.
Problem:
I try to install busybox.
Setup: - buildroot uclibc toolchain, eabi, gcc-4.2.1
- related buildroot root-fs with nothing more than
- ucClibc on it (I know it
hey (:
> I pushed a pretty big patch recently changing the way execve works, it's
> possible I made a mistake :)
no offense, but I hope so (((-; this way I could lean back and wait till u
fixed itif it is me who messed up, it's more work *g* just kidding
>
> Could you send the relevant line
Hi!
I just updated my source via git and rebuilt SB2...
when I now log in and try ./configure inside some source dir I get:
[SB2] [EMAIL PROTECTED] ~/sources/dropbear-0.50 $ ./configure
configure: WARNING: you should use --build, --host, --target
configure: WARNING: invalid host type: ./configur
Hi there!
After successfully (?) installing SB2, I tried to build ncurses...built went
fine, but installation not that good... actually the "make install"
called /usr/bin/install which in turn tried to put files in the host /usr/*
structure, not the buildroot one...
My question:
is this an in
(: ok bruteforce-installed the debian version of qemu, set the variable to
qemu-arm and with the proper buildroot root-fs the libtool script runs thru
successfully (:
Thx for your help, now I can start playing around with sb2!! (:
This is awesome!
Harry
I know these are all quite some newbie probs so I apologize for this...
Anyways, I recompiled the toolchain (without --sysroot option) and voila, crt*
and co are found in the toolchain dirs, without putting them in the buildroot
structure... I actually can compile a "hello world" program inside
(using the buildroot toolchain again, gcc 4.1.2, uclibc, eabi)
Well, it looks like the toolchain depends on certain files like crt*.o to be
in a fixed place (in this case /usr/lib , which also is the the dir-path
under the toolchain's root where those files are due to --with-sysroot=
usage??) .
found
What am I doing wrong/overlook?
Thanx for your help,
Harald Radke
___
Scratchbox-users mailing list
Scratchbox-users@lists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
Hi!
Is there something like a mailiing list dedicated to scratchbox2? As quite
crosscompile-inexperienced but quite motivated wannabe-programmer I'd like to
find the right place for questions/problems without annoying the wrong ppl.
Thx
Harry
___
S
18 matches
Mail list logo