Compiling Jansson for arm-linux

[rAm]

Hi All,

Thanks Peri for this wonderful library, it's truly awesome.

Coming to my problem. I have a POS device which runs arm linux. I am writing a connected application which runs on the device. The data format chosen is json and i found jansson really light and fits all my needs perfectly. The program I wrote compiles well with gcc for x86 and runs well on my development environment.

However when I try to compile it for device, I get errors.I fixed a few of them (related to position of declaring the variables). I get the following error:

pack_unpack.o: In function `json_vpack_ex':

/home/ramjee/Work/Projects/learning/jansson/src/pack_unpack.c:509: undefined reference to `va_copy'

/home/ramjee/Work/Projects/learning/jansson/src/pack_unpack.c:509: relocation truncated to fit: R_ARM_PC24 va_copy

pack_unpack.o: In function `json_vunpack_ex':

/home/ramjee/Work/Projects/learning/jansson/src/pack_unpack.c:572: undefined reference to `va_copy'

/home/ramjee/Work/Projects/learning/jansson/src/pack_unpack.c:572: relocation truncated to fit: R_ARM_PC24 va_copy

collect2: ld returned 1 exit status

make: *** [test_apl] Error 1

Compiler used: arm-linux-gcc.  This comes with arm-linux_gcc_2.95.2_2.i386.rpm.

Please suggest how to workaround this issue.

Thakns,

Ramjee Ganti

[Basile Starynkevitch]

On Sat, 19 Mar 2011 02:14:45 -0700 (PDT)
rAm <gan...@gmail.com> wrote:
>
> However when I try to compile it for device, I get errors.I fixed a few of
> them (related to position of declaring the variables). I get the following
> error:
>
> pack_unpack.o: In function `json_vpack_ex':
> /home/ramjee/Work/Projects/learning/jansson/src/pack_unpack.c:509: undefined
> reference to `va_copy'

> Compiler used: arm-linux-gcc. This comes with
> arm-linux_gcc_2.95.2_2.i386.rpm.
................^^^^^^

This is probably the problem.
I cannot understand why people are using a decade-old GCC compiler on ARM. GCC 2.95 is well known to be buggy, old, badly optimizing, not very standard compliant.

GCC 4.6.0 RC was released a few days ago. http://gcc.gnu.org/ml/gcc/2011-03/msg00179.html

I would suggest you to build a cross GCC compiler using the just released GCC 4.6 RC tar ball.
Or at least, something more recent, as gcc 4.5.2.

If a recent GCC cross-compiler gives you warnings with -Wall, please correct your software (or libraries) first.

Using an old GCC 2.95.x or even 3.y compiler for cross-compilation for ARM is a huge mistake.

Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

[rAm]

Hi Basile,

Thanks for the reply. Understand that I am using an old compiler. The situation is like this:

The POS device is given by the vendor and the tool chain is also given by them. So it is not just the question of just GCC but the entire toolchain. I will talk to the vendor to provide specific toolchain but I doubt that is something that can be done fast.

Can anyone provide a workaround this problem? It looks like something to do with copying the variables. It's almost 10years since I coded in C so not sure how to workaround in the code.

Thanks,

Ramjee Ganti

[Basile Starynkevitch]

On Sat, 19 Mar 2011 05:54:59 -0700 (PDT)
rAm <gan...@gmail.com> wrote:

> [...] The situation is like this:

>
> The POS device is given by the vendor and the tool chain is also given by
> them. So it is not just the question of just GCC but the entire toolchain. I
> will talk to the vendor to provide specific toolchain but I doubt that is
> something that can be done fast.
>
> Can anyone provide a workaround this problem? It looks like something to do
> with copying the variables. It's almost 10years since I coded in C so not
> sure how to workaround in the code

Nop! va_copy is the new standard conforming way to deal with variable
arguments list (like those for printf, as an example). It has nothing
to deal with "copying the variables"!! Your toolchain is so old that it
is no more standard conforming. And GCC 2.95.x is known to be very
buggy!

I believe, since you tell us that you are not very used to C coding
today, that you should find (e.g. pay) someone to help you, very
probably by first being able to build a recent cross-compilation
toolchain, and then by compiling jansson for you.

I hope I won't be in contact with an embedded product compiled by a
decade old buggy compiler (and since I am working on GCC
professionally, I do know that 2.95.x was bad!)

So my belief is that you have no easy & quick solution (unless you can
afford delivering a crippled system). You should get resources to get a
newer toolchain (e.g. paying someone for it, or building it yourself,
or buying it). It takes time & money!

The toolchain is free (GPLv3) software (that is, GCC + binutils +
glibc... and perhaps more). So you could in theory take time & effort
to build it. I have no idea what is, in your particular case, the best
solution (recompile tools by yourself, or pay someone to do that).

Your [common] situation reminds us that free software is free as in
speech (libre), not free as in beer (gratis). Obviously, getting a newer
usable toolchain costs resources (the time, expertise, & efforts to
build them).

But be assured of one point: the va_copy bug you are encountering is
one symptom that your toolchain is too old and crippled. Even if you
make a workaround against this particular bug, your GCC-2.95.x based
toolchain stays in very bad shape. And the software you are building
with such an ugly & buggy toolchain is not in good shape neither. You
will surely encounter other toolchain bugs (and some are much more
mysterious and naughty that the one you hit today!)

You have my empathy, since I understand that it is mostly a matter of
getting resources from your management and/or clients. I am sorry I
cannot help you on that matter.

But staying with GCC 2.95.x is a mistake in 2011, no matter what your
reasons are. It is notoriously a bad compiler, and GCC contributors
have worked a big lot to make current GCC (e.g. 4.5.2) much better.
Likewise for other parts of the toolchain (binutils, glibc, ... other
GNU software).

Good luck.

[Jonathan Landis]

On Sat, 2011-03-19 at 02:14 -0700, rAm wrote:
> /home/ramjee/Work/Projects/learning/jansson/src/pack_unpack.c:509:
> undefined reference to `va_copy'

A possible workaround is to use an older version of Jannson. The
pack_unpack code is new in 2.0, and I don't think the earlier version
(1.3) uses va_copy anywhere.

Both old source tarballs and old documentation are available on the
Jansson site. Check the "Releases" section.

http://www.digip.org/jansson/

JKL

[rAm]

Hi JKL,

Thanks a lot, I think that might be the way to go.

However, I found a work around. In the specified compiler under stdarg.h __va_copy is defined. I could successfully compile the code with this modification. I am yet to test if there is any effect at run time. I will update the post with what I do finally.

Also, can you suggest how to test this function (when this is called?).

Thanks,
Ramjee Ganti.

[rAm]

Hi Basile,

Thanks for the detailed comment. Understand that the toolchain is old. What I am working on is a very small application. And as mentioned in my other reply to JKL I kind of found a workaround and if I cannot make it work, will choose a 1.3 of Jansson. However, agree with you on updating the tool chain. I will definitely pass on this detail to the POS manufacturer.

I am also taking help from a friend of mine who is really good at this stuff and learn to build toolchain.(more from personal interest than for work).

Thanks,
Ramjee Ganti

[Jonathan Landis]

On Sat, 2011-03-19 at 12:10 -0700, rAm wrote:
> Also, can you suggest how to test this function (when this is
> called?).

Here is what it says about va_copy in the autoconf manual:

"The C99 standard provides va_copy for copying va_list variables. It may
be available in older environments too, though possibly as __va_copy
(e.g., gcc in strict pre-C99 mode). These can be tested with #ifdef. A
fallback to memcpy (&dst, &src, sizeof (va_list)) gives maximum
portability."

http://www.gnu.org/software/hello/manual/autoconf/Function-Portability.html#Function-Portability

If that is correct, what you are doing is fine. In fact, instead of
modifying the source files, I think you can just modify your configure
command and use the sources as-is. Try something like:

./configure CFLAGS=-Dva_copy=__va_copy

JKL

[Petri Lehtinen]

While I agree with Basile, you, as a developer with little power over
the toolchain, have my sympathy :)

You can run the test suite by invoking "make check". The pack/unpack
functionality that use va_copy() is covered by the test suite, so any
problems should be detected.

I also added to jansson_private.h a test for the existence of
va_copy(), falling back to __va_copy() and then memset():

https://github.com/akheron/jansson/commit/b90ed1ac

It seems 2.0.1 could be released soon, as some good fixes already in.

Petri

[Basile Starynkevitch]

On Sun, 20 Mar 2011 21:32:26 +0200
Petri Lehtinen <pe...@digip.org> wrote:
> While I agree with Basile, you, as a developer with little power over
> the toolchain, have my sympathy :)

I wrote about my empathy. English not being my native language, we
probably mean the same!

> I also added to jansson_private.h a test for the existence of
> va_copy(), falling back to __va_copy() and then memset():

You probably mean memcpy not memset. However, I would suggest that your
configury machinery issues a warning if va_copy is really used (I
believe it is), and if it not available.

Regards

[rAm]

Hi,

@Basile,@Petri, @JKL,

Thanks a lot for all the help.
I finally settle for Petri's suggestion.

Thanks,
Ramjee Ganti

[Petri Lehtinen]

Basile Starynkevitch wrote:
> On Sun, 20 Mar 2011 21:32:26 +0200
> Petri Lehtinen <pe...@digip.org> wrote:
> > While I agree with Basile, you, as a developer with little power over
> > the toolchain, have my sympathy :)
>
> I wrote about my empathy. English not being my native language, we
> probably mean the same!

Yes, not my native language either :)

> > I also added to jansson_private.h a test for the existence of
> > va_copy(), falling back to __va_copy() and then memset():
>
> You probably mean memcpy not memset. However, I would suggest that your
> configury machinery issues a warning if va_copy is really used (I
> believe it is), and if it not available.

Yes, memcpy() of course.

[Basile Starynkevitch]

On Sat, 19 Mar 2011 08:09:41 -0700
Jonathan Landis <jkla...@gmail.com> wrote:

> On Sat, 2011-03-19 at 02:14 -0700, rAm wrote:
> > /home/ramjee/Work/Projects/learning/jansson/src/pack_unpack.c:509:
> > undefined reference to `va_copy'
>
> A possible workaround is to use an older version of Jannson. The
> pack_unpack code is new in 2.0, and I don't think the earlier version
> (1.3) uses va_copy anywhere.
>

Another workaround could be to remove all the variable argument related
functons new in jansson 2.0.

However, I still recommend against using old gcc 2.95.x, see details in
my previous emails.

Cheers