qemu/glib fails to build with newer gcc

[Martin Erik Werner]

The rsb qemu build fails on Debian Stretch with the following error:

CC libglib_2_0_la-gdate.lo

../../glib-2.39.3/glib/gdate.c: In function 'g_date_strftime':
../../glib-2.39.3/glib/gdate.c:2497:7: error: format not a string literal, format string not checked [-Werror=format-nonliteral]

tmplen = strftime (tmpbuf, tmpbufsize, locale_format, &tm);
^~

I experimented around a bit and if glib is updated to version 2.48.2 this seems to be solved, but then it instead fails due to a missing libpcre dependency.

I tried forcing the internal version of pcre instead, and that seemed to at least make the build go through.

The experimentation I did is attached as a patch.

I tested the build result qemu-system-or32 briefly, and I'm not sure it works properly in the end:

$ ~/utv/rtems-build/5/bin/qemu-system-or32

(process:18292): GLib-WARNING : ../../glib-2.48.2/glib/gmem.c:483: custom memory allocation vtable not supported
qemu: fatal: Trying to execute code outside RAM or ROM at 0x08000000

PC=08000000
R00=00000000 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=00000000 R14=00000000 R15=00000000
R16=00000000 R17=00000000 R18=00000000 R19=00000000
R20=00000000 R21=00000000 R22=00000000 R23=00000000
R24=00000000 R25=00000000 R26=00000000 R27=00000000
R28=00000000 R29=00000000 R30=00000000 R31=00000000
Aborted

$ ~/utv/rtems-build/5/bin/qemu-system-or32 -serial mon:stdio -kernel ~/utv/rtems-build/bsp-generic_or1k-build/or1k-rtems5/c/generic_or1k/testsuites/samples/hello.exe

(process:5042): GLib-WARNING : ../../glib-2.48.2/glib/gmem.c:483: custom memory allocation vtable not supported

(nothing more happens...)

[Joel Sherrill <joel@…>]

In 37e7cc5/rtems:

gdbarmsim: Remove

Closes #3611.

[Joel Sherrill <joel@…>]

In 87e49d4/rtems-docs:

gdbarmsim: Remove all references to this deleted BSP family

Updates #3611.

[Martin Erik Werner]

I'm guessing this should be re-opened since the commit used the wrong close ticket id?

(I have not re-tested this on current versions of Debian though.)

[Joel Sherrill]

I'm sorry. I misread #3611 instead of #3911.

I pushed this. Hopefully someone can test it but we know this has been broken for a while on newer OSes. With any luck, you didn't make it worse on older ones. :)