Unable to build from command line, Ubuntu 12.10

[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!

[singpolyma]

Full config.log at http://pastie.org/5375098

[jnicholl]

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]

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]

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]

Hmm. What version of ndk are you using? I'm a bit at a loss, so trying to figure out differences between your system and mine.

From: Stephen Paul Weber [mailto:notifications@github.com]
Sent: Wednesday, November 14, 2012 05:40 PM
To: blackberry/SDL SDL@noreply.github.com
Cc: Jeremy Nicholl
Subject: Re: [SDL] Unable to build from command line, Ubuntu 12.10 (#34)

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?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/34#issuecomment-10389193.

---

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

[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]

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

[jnicholl]

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.