Problem compiling with IBM xlc - -Wall flag only works with gcc like compliers

770 views
Skip to first unread message

Michael Felt

unread,
Oct 1, 2015, 3:34:08 AM10/1/15
to json-c
I am almost thinking there is a tutorial which has -Wall hard-coded into 
error checking for configure.ac input. In any case, this is a configure 
error I am encountering very very frequently since the beginning of this 
year.

When I get a reply to this I will have the syntax for xlc available - 
again. I should have kept it around last time I researched it for 
another project.

Michael

The error I during make is:
+ /opt/bin/make > .buildaix/make.out
xlc: 1501-210 (S) command option Wall contains an incorrect subargument

Michael Felt

unread,
Oct 1, 2015, 3:39:25 AM10/1/15
to json-c
I think MANY of the flags are going to fail -

AM_CFLAGS = -Wall -Werror -Wno-error=deprecated-declarations -Wextra -Wwrite-strings -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -D_REENTRANT

Already failed with -Werror and -Wno-error=deprecated-declarations

And, how far off is gnu99 from c99 or c99extended?

Has anyone ever tried using a non-GNU compiler?

Michael Felt

unread,
Oct 1, 2015, 4:38:09 AM10/1/15
to json-c
-Wall - the closest xlC flag would be -qinfo=all

-Werror - is to make all warning messages an error, and then the list of exceptions - I guess initially I would skip that with xlC until I have better knowledge of what I am trying to not do. However, the flag to do -Werror is -qhalt=w (stop for any error or warning) or -qhalt=e (stop for any error, but permit warnings). Not doing anything sets -qhalt=s (server and/or unrecoverable error only), to be more strict set -qhalt=i (stop for any message, informational)

-std=gnu99 is best replaced by -qlanglvl=extc99

So - I am going to try
AM_CFLAGS = -qinfo=all -qlanglvl=extc99 -D_GNU_SOURCE -D_REENTRANT

Michael Felt

unread,
Oct 1, 2015, 4:43:31 AM10/1/15
to json-c
FYI - much further, but still a bad (now linker flag), and a few undefined symbols.

Will update later when I have time to try again - for now -

make[2]: Entering directory `/data/prj/aixtools/json-c-0.12'
/bin/sh ./libtool  --tag=CC   --mode=link xlc -qlanglvl=extc99 -D_GNU_SOURCE -D_REENTRANT -I/opt/include -I/opt/buildaix/include -O2 -version-info 2:1:0 -no-undefined -Wl,-Bsymbolic-functions  -o libjson-c.la -rpath /opt/lib arraylist.lo debug.lo json_c_version.lo json_object.lo json_object_iterator.lo json_tokener.lo json_util.lo linkhash.lo printbuf.lo random_seed.lo  
libtool: link: rm -fr  .libs/libjson-c.exp
libtool: link: /usr/bin/nm -B -BCpg  .libs/arraylist.o .libs/debug.o .libs/json_c_version.o .libs/json_object.o .libs/json_object_iterator.o .libs/json_tokener.o .libs/json_util.o .libs/linkhash.o .libs/printbuf.o .libs/random_seed.o   | awk '{ if ((($ 2 == "T") || ($ 2 == "D") || ($ 2 == "B")) && (substr($ 3,1,1) != ".")) { print $ 3 } }' | sort -u > .libs/libjson-c.exp
libtool: link: xlc -Wl,-bM:SRE -o .libs/libjson-c.so.2  .libs/arraylist.o .libs/debug.o .libs/json_c_version.o .libs/json_object.o .libs/json_object_iterator.o .libs/json_tokener.o .libs/json_util.o .libs/linkhash.o .libs/printbuf.o .libs/random_seed.o   -lc -Wl,-bnoentry  -qlanglvl=extc99 -O2 -Wl,-Bsymbolic-functions   -Wl,-bE:.libs/libjson-c.exp -Wl,-bernotok
ld: 0706-027 The -B symbolic-functions flag is ignored.
ld: 0711-317 ERROR: Undefined symbol: .rpl_realloc
ld: 0711-317 ERROR: Undefined symbol: .rpl_malloc
ld: 0711-317 ERROR: Undefined symbol: ._isnan
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
make[2]: *** [libjson-c.la] Error 8
make[2]: Leaving directory `
/data/prj/aixtools/json-c-0.12'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/data/prj/aixtools/json-c-0.12'

make
: *** [all] Error 2



Further, -qinfo=all is overkill - getting MANY MANY messages such as:
"/usr/include/time.h", line 292.2: 1506-460 (I) else nesting level is 3.
"/usr/include/time.h", line 292.2: 1506-456 (I) Stop skipping tokens.
"/usr/include/time.h", line 300.2: 1506-460 (I) if nesting level is 4.
"/usr/include/time.h", line 300.13: 1506-455 (I) defined(_THREAD_SAFE) evaluates to 0.
"/usr/include/time.h", line 300.2: 1506-454 (I) if condition evaluates to 1.
"/usr/include/time.h", line 307.2: 1506-460 (I) endif nesting level is 4.

Eric Haszlakiewicz

unread,
Oct 1, 2015, 10:55:03 AM10/1/15
to jso...@googlegroups.com


On Oct 1, 2015 4:43 AM, "Michael Felt" <aixt...@gmail.com> wrote:
> FYI - much further, but still a bad (now linker flag), and a few undefined symbols.
>
> Will update later when I have time to try again - for now -
>
> make[2]: Entering directory `/data/prj/aixtools/json-c-0.12'
> /bin/sh ./libtool  --tag=CC   --mode=link xlc -qlanglvl=extc99 -D_GNU_SOURCE -D_REENTRANT -I/opt/include -I/opt/buildaix/include -O2 -version-info 2:1:0 -no-undefined -Wl,-Bsymbolic-functions  -o libjson-c.la -rpath /opt/lib arraylist.lo debug.lo json_c_version.lo json_object.lo json_object_iterator.lo json_tokener.lo json_util.lo linkhash.lo printbuf.lo random_seed.lo  

Are those options (e.g. -Bsymbolic-functions) specified in the json-c sources somewhere?  If not, maybe there's something wrong with your copy of libtool.

> libtool: link: xlc -Wl,-bM:SRE -o .libs/libjson-c.so.2  .libs/arraylist.o .libs/debug.o .libs/json_c_version.o .libs/json_object.o .libs/json_object_iterator.o .libs/json_tokener.o .libs/json_util.o .libs/linkhash.o .libs/printbuf.o .libs/random_seed.o   -lc -Wl,-bnoentry  -qlanglvl=extc99 -O2 -Wl,-Bsymbolic-functions   -Wl,-bE:.libs/libjson-c.exp -Wl,-bernotok
> ld: 0706-027 The -B symbolic-functions flag is ignored.
> ld: 0711-317 ERROR: Undefined symbol: .rpl_realloc
> ld: 0711-317 ERROR: Undefined symbol: .rpl_malloc

Huh?  Your system doesn't include malloc in libc?  If it's in some other library I would think that libtool would know enough to include it.

> ld: 0711-317 ERROR: Undefined symbol: ._isnan

Fixing this probably needs a -lm added.

> Further, -qinfo=all is overkill - getting MANY MANY messages such as:
> "/usr/include/time.h", line 292.2: 1506-460 (I) else nesting level is 3.

It sounds more like qinfo isn't the same thing as gcc's warnings.  For instance, it would make sense to cause the build to fail because of any of these messages you listed.
If there isn't an equivalent set of options, then just drop them altogether.  The -W options don't change the compiled output, so it's just a matter of how resilient you want to be to catching stupid programming mistakes when building on your system.

Eric

Eric Haszlakiewicz

unread,
Oct 1, 2015, 10:55:03 AM10/1/15
to jso...@googlegroups.com


On Oct 1, 2015 3:34 AM, "Michael Felt" <aixt...@gmail.com> wrote:
>
> I am almost thinking there is a tutorial which has -Wall hard-coded into
> error checking for configure.ac input. In any case, this is a configure
> error I am encountering very very frequently since the beginning of this
> year.

You must not have been looking at many OS targeted builds before the beginning of the year; it seems to me to be a common occurrence for quite some time.  IMO, using appropriate options to turn on compile time error checking is a good idea, and since json-c has mainly been used on systems that have gcc as their compiler (Linux, NetBSD, etc...), the fact that -Wall, et al. are hard coded is entirely reasonable.

> When I get a reply to this I will have the syntax for xlc available -
> again. I should have kept it around last time I researched it for
> another project.

If you know the appropriate autoconf/automake syntax to override the default flags when building with another compiler, such as xlc, I'll be happy to merge in a patch.

Eric

Michael Felt

unread,
Oct 15, 2015, 8:03:27 AM10/15/15
to jso...@googlegroups.com
This has been on the back burner due to work.

I think IBM xlc "warnings", with no additional arguments - are close to -Wall for gcc. I certainly see many messages going to stderr all the time.

-B... no idea where that is coming from, maybe just a hard-coded something like -Wall is.

re: *alloc* - there are lots of definitions, just none with rpl in the name

root@x064:[/data/prj/gnu/libiconv/libiconv-1.14]nm /usr/lib/libc.a | grep alloc | wc -l
303
root@x064:[/data/prj/gnu/libiconv/libiconv-1.14]nm /usr/lib/libc.a | grep rpl | wc -l
0


--
You received this message because you are subscribed to the Google Groups "json-c" group.
To unsubscribe from this group and stop receiving emails from it, send an email to json-c+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Eric Haszlakiewicz

unread,
Oct 21, 2015, 11:03:15 PM10/21/15
to jso...@googlegroups.com
On Thu, Oct 15, 2015 at 8:03 AM, Michael Felt <aixt...@gmail.com> wrote:
This has been on the back burner due to work.

I think IBM xlc "warnings", with no additional arguments - are close to -Wall for gcc. I certainly see many messages going to stderr all the time.

-B... no idea where that is coming from, maybe just a hard-coded something like -Wall is.

We can fix this by using AX_APPEND_FLAG from the Autoconf Archive to figure out what flags the compiler accepts.  I'm pretty sure I know how to get that to work, so when I have a bit more time I'll take a look at implementing it.
 
re: *alloc* - there are lots of definitions, just none with rpl in the name

This is due to the use of AC_FUNC_MALLOC in configure.ac, which is supposed to be paired with a rpl_malloc() replacement implementation.  Because I don't think it's necessary I removed it, so you should be able to build at least without those errors now.

Eric

Eric Haszlakiewicz

unread,
Oct 22, 2015, 10:22:56 PM10/22/15
to jso...@googlegroups.com
On Wed, Oct 21, 2015 at 11:03 PM, Eric Haszlakiewicz <haw...@gmail.com> wrote:
On Thu, Oct 15, 2015 at 8:03 AM, Michael Felt <aixt...@gmail.com> wrote:
This has been on the back burner due to work.

I think IBM xlc "warnings", with no additional arguments - are close to -Wall for gcc. I certainly see many messages going to stderr all the time.

-B... no idea where that is coming from, maybe just a hard-coded something like -Wall is.

We can fix this by using AX_APPEND_FLAG from the Autoconf Archive to figure out what flags the compiler accepts.  I'm pretty sure I know how to get that to work, so when I have a bit more time I'll take a look at implementing it.

I just checked in a change to do this.  Also, you should be able to disable the use of the -Bsymbolic by passing --disable-Bsymbolic to configure.  Give it a shot and let me know how it goes.

Eric

Michael Felt

unread,
Oct 23, 2015, 6:49:31 AM10/23/15
to jso...@googlegroups.com
Thanks. Reloaded the build system to clear away any trace of history
from other things. Will let you know - I hope later today - how things
proceed.
Reply all
Reply to author
Forward
0 new messages