Reply
Thread Tools
allnameswereout's Avatar
Posts: 3,397 | Thanked: 1,212 times | Joined on Jul 2008 @ Netherlands
#11
Originally Posted by Nathan View Post
Ok, maybe you can explain how; because I am obviously missing something. Cmake detects that it is in x86 when I'm in the fremantle x86 target, and armel when I'm in the fremantle armel target. What is the point of the armel target if not to compile the code.

Nathan.
Normally, with configure, you can tell --target=arm-linux. You should check the cmake config file (which it reads before make) to see if you can specify this.

When I had to use cmake I had to work around it, although IIRC I tried various versions of cmake and got one to work. I think I just grabbed one from Debian.

From the mentioned mailing list it appears its a QEMU bug.

It also says, that the cmake in extras-devel only works in Scratchbox; not on the device itself. In your case this doesn't matter because, like most people, you're going to use it in your SDK anyway.
__________________
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
 
Posts: 452 | Thanked: 522 times | Joined on Nov 2007
#12
Thanks -- I have re-opened the discussion on the mailing list. This needs to get resolved.

Nathan.
 
Posts: 452 | Thanked: 522 times | Joined on Nov 2007
#13
Originally Posted by allnameswereout View Post
Normally, with configure, you can tell --target=arm-linux. You should check the cmake config file (which it reads before make) to see if you can specify this.

When I had to use cmake I had to work around it, although IIRC I tried various versions of cmake and got one to work. I think I just grabbed one from Debian.
I'm not sure what you are trying to say. Afaik, the only way to compile inside the scratchbox a armel version of a application is to actually have the "armel" as the current scratchbox target. Otherwise it will be picking up x86 libraries. Afaik, in SB1 the current target controls what libraries/headers are found by the compilers. Even if I did a cmake with some magic change to the control file; it won't solve the issue of compiling it inside the armel target. As then cmake will find all my x86 stuff, and I won't know if I'm missing any armel dependancies.

From the mentioned mailing list it appears its a QEMU bug.
Correct.

It also says, that the cmake in extras-devel only works in Scratchbox; not on the device itself. In your case this doesn't matter because, like most people, you're going to use it in your SDK anyway.
Yes, that is a proposed solution -- but it has NOT been implemented yet. Cmake is broken in the armel target. It works fine on the x86 target. The proposed solution is to create a "host" cmake version which can run under either the armel or the x86 targets. But it has not been done, and afaik the build-bots also would have the same cmake issue; meaning packages I submit using cmake won't build...

Nathan.
 
Posts: 452 | Thanked: 522 times | Joined on Nov 2007
#14
I've added a bug in the bugtracker
https://bugs.maemo.org/show_bug.cgi?id=5488

Nathan
 

The Following User Says Thank You to Nathan For This Useful Post:
allnameswereout's Avatar
Posts: 3,397 | Thanked: 1,212 times | Joined on Jul 2008 @ Netherlands
#15
I read wrong. I thought what was being tried is compiling cmake for ARMEL instead of using it.

Now, to quote, host-gcc and host-g++ should work in the SDK.

I think you got it wrong... It will build with host-g++/host-gcc, so
it will be built with the same compiler (and linked to the same
libraries) as other internal sbox tools were compiled. Therefore, if
scratchbox works in your host, cmake compiled with host-g++ will work
too. It will not link to any host libraries, only to internal
scratchbox ones.

Unless you did not use the official sbox binaries (e.g. compiled from
sources) it should work.

If you don't know, "host-g++" is a internal scratchbox compiler used
to compile all "native" tools provided by scratchbox, that work on
both targets.
it will just work, because cmake compiled with host-g++ will work like any other scratchbox internal tool.
So, in sbox this should work, if Anderson Lizardo shares the diff for the modified cmake we can built it ourselves for sbox. Or if he shares binary as unofficial devkit.

Btw, cmake is not broken; the problem lies in QEMU. Somewhere in QEMU...
__________________
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
 
Posts: 452 | Thanked: 522 times | Joined on Nov 2007
#16
Originally Posted by allnameswereout View Post
I read wrong. I thought what was being tried is compiling cmake for ARMEL instead of using it.
Actually that was one of the steps I was about to try doing. Until I found out it wouldn't work based on the newsgroup post. I've made several "later" versions of different tools while testing things. I even have the cmake 2.6.4 source in my scratchbox... ;-)


Now, to quote, host-gcc and host-g++ should work in the SDK.
Yes, I started to look into doing this.


So, in sbox this should work, if Anderson Lizardo shares the diff for the modified cmake we can built it ourselves for sbox. Or if he shares binary as unofficial devkit.
I also opened another thread on the newgroups to see if we can pin this down and get it fixed. Apparently a host mode cmake was supposed to be delivered with the final sdk (to solve this problem) and the ball was dropped. They (Nokia) are looking into what happened and how to get it resolved according to a newgroup post in response to the new thread I started.

Btw, cmake is not broken; the problem lies in QEMU. Somewhere in QEMU...
Correct, but for all practically purposes it is only currently affecting cmake. So if doing a host mode version of cmake fixes the problem; then this is a "easy" fix. Tracking down why cmake doesn't like the patched scratchbox qemu verson would probably be a pita, since it is only in the armel target it crashes.

Nathan.
 

The Following User Says Thank You to Nathan For This Useful Post:
Posts: 452 | Thanked: 522 times | Joined on Nov 2007
#17
Well it looks like we have a SOLUTION -- fresh today added to the sdk is a "sdk" version of cmake. I installed it and I am good to go. I can run cmake in both x86 and armel targets now.

http://maemo.org/packages/view/cmake/

Nathan.
 

The Following 6 Users Say Thank You to Nathan For This Useful Post:
Posts: 369 | Thanked: 191 times | Joined on Sep 2009 @ Virginia
#18
Thanks for running with the ball on this one
 
Posts: 452 | Thanked: 522 times | Joined on Nov 2007
#19
Originally Posted by Hogwash View Post
Thanks for running with the ball on this one
No problem. I figured if I posted the "problem" in enough places someone would get it off their todo list. ;-)

They move a LOT faster than I expected. I'm pretty impressed that a day later I have a solution that will work not only on my local sdk but should also work on the buildbots since it is now an official sdk tool.

Nathan.
 
Posts: 9 | Thanked: 2 times | Joined on Oct 2009
#20
Originally Posted by Nathan View Post
Well it looks like we have a SOLUTION -- fresh today added to the sdk is a "sdk" version of cmake. I installed it and I am good to go. I can run cmake in both x86 and armel targets now.

http://maemo.org/packages/view/cmake/

Nathan.
Thanks ! It's working.. this helps me very much.
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 17:42.