Comment 3 for bug 836588

Thank you for the bug report. I've confirmed this with gcc-linaro-4.6-2011.08 on ARM:

michaelh@ursa1:~/linaro/bugs$ /tools/toolchains/arch/armv7l/gcc-linaro-4.6-2011.08-armv7l-natty-cbuild162-ursa1-cortexa9r1/bin/gcc -c -O2 -fPIC -save-temps gmime2.i
gmime2.s: Assembler messages:
gmime2.s:1007: Error: can't resolve `.rodata' {.rodata section} - `.LPIC18' {*UND* section}

The assembler is correct - the code references a label which doesn't exist.

The suspicious code is around:
 bl g_hash_table_new(PLT)
 mov sl, r0
 add r0, sp, #32
 bl g_mime_decode_lwsp(PLT)
 ldr r3, .L146+24
 ldr r1, [sp, #4]
 str r3, [sp, #16]
 ldr r3, [sp, #32]
...
.L146:
...
 .word .LANCHOR0-(.LPIC18+4)

The 'ldr r3, .L146+24' references the offset. The value is spilt to the stack before the normal `add r3, pc` and doesn't seem to be used afterwards.

The work-around is to compile at -O1 or -O3. The fault also exists in gcc-4.6.1. It does not exist in gcc-4.5.3 or trunk r178025. Could you please also report this in GCC bugzilla and attach it to this ticket?

I've set it to medium priority as it is a ftbfs, a work around exists, and the fault exists on an upstream release branch.