Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Unable to build from command line, Ubuntu 12.10 #34

Open
singpolyma opened this Issue · 20 comments

3 participants

@singpolyma

I'm trying to build this for use with BB10 (actually, the simulator to start) from the command line on Ubuntu 12.10.

Trying the following:

$ git clone git://github.com/blackberry/SDL.git
$ cd SDL
$ . ~/bbndk/bbndk-env.sh
$ ./build_for_playbook.sh 
configure: WARNING: if you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used
checking for arm-unknown-nto-qnx6.5.0eabi-gcc... no
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/home/singpolyma/src/st-sdl/SDL':
configure: error: C compiler cannot create executables
See `config.log' for more details
make: *** No rule to make target `all'.  Stop.
Build Failed!
@jnicholl
Collaborator

It looks like for BB10, the compiler has changed from arm-unknown-nto-qnx6.5.0eabi-gcc to arm-unknown-nto-qnx8.0.0eabi-gcc. If you change that in the build_for_playbook.sh script you'll get further, but you'll still need to set up TouchControlOverlay. Have you done that yet?

@singpolyma

Interesting, so this build doesn't go through the qcc wrapper? I've built TouchControlOverlay, though I'm not sure where the files should go so that the SDL build can find them.

@jnicholl
Collaborator

This build used to use qcc, but Aaron Small pointed out that using the qcc wrapper actually provides an interface further from the standard gcc than using the prefixed gcc binary. This often means that the adaptation for cross-compiling is easier.
When building using configure, TouchControlOverlay is expected to be installed into the NDK staging area, both headers and library.

@singpolyma

I just did make install on TouchControlOverlay for now, so it found it, though that's probably not a long-term solution. I made a script where I set the build to i486-pc-nto-qnx8.0.0 because that seems to be the string for the simulator. Build fails with:

/bin/bash ./libtool --mode=compile i486-pc-nto-qnx8.0.0-gcc -g  -D__PLAYBOOK__ -D__QNXNTO__  -I./include -D_GNU_SOURCE=1  -c ./src/video/SDL_RLEaccel.c  -o build/SDL_RLEaccel.lo
libtool: compile:  i486-pc-nto-qnx8.0.0-gcc -g -D__PLAYBOOK__ -D__QNXNTO__ -I./include -D_GNU_SOURCE=1 -c ./src/video/SDL_RLEaccel.c  -fPIC -shared -DPIC -o build/.libs/SDL_RLEaccel.o
/tmp/cc2zkevH.s: Assembler messages:
/tmp/cc2zkevH.s:1373: Error: unsupported for `movq'
/tmp/cc2zkevH.s:2273: Error: unsupported for `movq'
/tmp/cc2zkevH.s:3429: Error: unsupported for `movq'
/tmp/cc2zkevH.s:3945: Error: unsupported for `movq'
/tmp/cc2zkevH.s:5809: Error: unsupported for `movq'
/tmp/cc2zkevH.s:6511: Error: unsupported for `movq'
/tmp/cc2zkevH.s:7403: Error: unsupported for `movq'
/tmp/cc2zkevH.s:7788: Error: unsupported for `movq'
make: *** [build/SDL_RLEaccel.lo] Error 1
Build Failed!
@singpolyma

If I comment out SDL_ASSEMBLY_ROUTINES in includes/SDL_config.h then it moves on to this error:

/home/singpolyma/bbndk/host_10_0_9_52/linux/x86/usr/bin/ntox86-ld: read-only segment has dynamic relocations.
collect2: ld returned 1 exit status
make: *** [build/libSDL.la] Error 1
@jnicholl
Collaborator

Hmm. I'm confused. I can build it just fine. Is it possible you have object files left over from building with ARM that it's trying to link for simulator?

@singpolyma

Just tried with a fresh clone of the repo, same thing. This is the build script I'm using: http://pastie.org/5377123

@singpolyma

If I use this script instead: http://pastie.org/5379536 which builds for the device (ARM) it works. So maybe there's an assumption somewhere that breaks when building for x86?

@jnicholl
Collaborator
@singpolyma

I just downloaded the NDK a few days ago. I have folders named host_10_0_9_52, target_10_0_9_386, and ndk-10.0.9-workspace, so I'm guessing that's the version.

I'm running Ubuntu 12.10, a fairly recent install (technically LUbuntu 12.10, but the base system that matters is all the same).

$ uname -a
Linux singpolyma-beefy 3.5.0-18-generic #29-Ubuntu SMP Fri Oct 19 10:27:31 UTC 2012 i686 i686 i686 GNU/Linux

$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
stepping : 10
microcode : 0xa07
cpu MHz : 2000.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dtherm tpr_shadow vnmi flexpriority
bogomips : 5999.20
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
stepping : 10
microcode : 0xa07
cpu MHz : 2000.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dtherm tpr_shadow vnmi flexpriority
bogomips : 5999.20
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

$ cat /proc/meminfo
MemTotal: 4132908 kB
MemFree: 3312008 kB
Buffers: 37928 kB
Cached: 459544 kB
SwapCached: 0 kB
Active: 374700 kB
Inactive: 348000 kB
Active(anon): 233108 kB
Inactive(anon): 1536 kB
Active(file): 141592 kB
Inactive(file): 346464 kB
Unevictable: 32596 kB
Mlocked: 32596 kB
HighTotal: 3279560 kB
HighFree: 2545728 kB
LowTotal: 853348 kB
LowFree: 766280 kB
SwapTotal: 4191228 kB
SwapFree: 4191228 kB
Dirty: 896 kB
Writeback: 0 kB
AnonPages: 257888 kB
Mapped: 67768 kB
Shmem: 2324 kB
Slab: 25444 kB
SReclaimable: 13624 kB
SUnreclaim: 11820 kB
KernelStack: 2264 kB
PageTables: 3812 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 6257680 kB
Committed_AS: 1207348 kB
VmallocTotal: 122880 kB
VmallocUsed: 48680 kB
VmallocChunk: 63476 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 61432 kB
DirectMap2M: 851968 kB

NDK installed to $HOME/bbndk/

@singpolyma

Full script output, including ./configure for the failing x86 build: http://pastie.org/5379633

@asimonov-im

Alright, I can reproduce it. It was my fault earlier, I didn't properly clean at some point and it was using a different TouchControlOverlay. I haven't managed to get very far with solving it however, aside from finding that it's a problem with linking TouchControlOverlay (if you just remove it from linking then you don't get the same issues).
Your solution of --enable-assembly=no to remove SDL_ASSEMBLY_ROUTINES also seems to be necessary.

@jnicholl
Collaborator

(sorry about that, posting from the wrong computer and didn't realize I wasn't signed in as me)

@jnicholl
Collaborator

I haven't figured out a good solution yet, but a workaround for now is to comment out CheckTouchControlOverlay in the configure for SDL and then when you build binaries, add TouchControlOverlay as a library to be linked at that point. This seems to work, but linking TouchControlOverlay with SDL originally does not. Also... it seems to work on device, just not simulator.

@singpolyma

The workaround seems to work, but if I do that then I cannot build things like SDL_ttf, because they need to link against SDL, but can't unless they also link against TCO (which, if I link against, I get a similar error).

Thanks for your work on this :)

@jnicholl
Collaborator
@jnicholl
Collaborator

After much investigation, I'm still confused!
I made sample libraries, one using C++ and one using C. The C library links to the C++ library when building. If I build for desktop with gcc, everything works. If I build with arm-unknown-nto-qnx8.0.0eabi-gcc for device, everything works. If I build with qcc -Vgcc_ntox86 for simulator, everything works. However, if I build with i486-pc-nto-qnx8.0.0-gcc for simulator, I get the linker error you found. Basically, that means the qcc wrapper is doing something hidden that i486-... isn't. I also found that if I use i486-pc-nto-qnx8.0.0-g++ even though I'm building a C library, that works too.
Given all the incompatibilities, I don't know whether this is simply a bug with the i486-...-gcc compiler (which admittedly most people never use directly) or whether I'm still doing something wrong with this. So I'm afraid I don't have any good solutions. The best solution would be for someone to rewrite TouchControlOverlay as a C library (also magically adding in all those features for resolution independence that it so desperately needs), but that doesn't seem likely in the short-term.
For now, I think our options are limited to workarounds. The two workarounds are either to switch back to using qcc and hard-coding compiler/linker flags or to stop linking TouchControlOverlay when building for simulator, and defer that link to the final executable link. I'm open to any other good suggestions. :)

@singpolyma

Either of those solutions could work for me. I need to look into how TCO works / what it does.

I got my app minimally running on the simulator this morning, thanks for the help! Now I just need to make it work, heh ;)

@jnicholl
Collaborator

I have some limited good news. I talked with the compiler folks and apparently this has already been reported to them. They have a fix on the way, but no ETA. They also suggest that adding -fpic (not -fPIC) to the linker command line will work as a simpler workaround. I haven't figured out how I would do that... (edit libtool?) but that's another option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.