Source for 3.7.2 fails to build for PPC

[Rama]

Hi,

I have to build for PPC as there seems no binary package.

ran configure with some options as below (most of the options are to cater for our build environment) :

bash ./configure  --with-pam=no --with-openssl=$INTERFACE_DIR --with-lmdb=${INTERFACE_DIR} LDFLAGS="-Bstatic -s -UHAVE_SNPRINTF -DHAVE_STDLIB_H -L$ADD_LIB_DIR" CFLAGS="-DHAVE_STDLIB_H -UHAVE_SNPRINTF -I$ADD_INC_DIR -I$ADD_INC_DIR/${PLATFORM}" CXXFLAGS="-DHAVE_STDLIB_H -UHAVE_SNPRINTF -I$ADD_INC_DIR -I$ADD_INC_DIR -L$ADD_LIB_DIR" --build=i386 --host=${HOST} CXX=${CROSS_COMPILE}g++ CC=${CROSS_COMPILE}gcc AR=${CROSS_COMPILE}ar LD=${CROSS_COMPILE}ld RANLIB=${CROSS_COMPILE}ranlib --with-masterdir=/var/cfengine/masterfiles --with-inputdir=/var/cfengine/inputs --with-workdir=/var/cfengine --libdir=/var/cfengine/lib 

Linker fails to resolve the "rpl_" symbols which are actually defined in snprintf.c enclosed deep inside conditional compiles.  I tried adding a few different defines and undefined to CFLAGS, CXXFLAGS and LDFLAGS, without much luck so far.

___________________

/home/rduggal/jats_cbuilder/rduggal_cfengine_3.6.5.1005.cots_19212/src/cfengine-3.7.2/libpromises/.libs/libpromises.so: undefined reference to `rpl_fprintf'

collect2: ld returned 1 exit status

xmake[2]: *** [cf-agent] Error 1

xmake[1]: *** [all-recursive] Error 1

make: *** [all] Error 2

xmake: *** [generate_files_0] Error 2

__________

Before I go disfiguring the original source tarball to work around this, someone may have encountered and made the build work ? I recall having build 3.6.5 by editing snprintf.c to place these functions outside the deeply nested conditional compiles, but would like to avoid if possible with 3.7.2

Cheers

Rama

[Kristian Amlie]

On 06/01/16 03:18, Rama wrote:
> Hi,
>
> I have to build for PPC as there seems no binary package.
>
> ran configure with some options as below (most of the options are to
> cater for our build environment) :
>
> bash ./configure --with-pam=no --with-openssl=$INTERFACE_DIR
> --with-lmdb=${INTERFACE_DIR} LDFLAGS="-Bstatic -s -UHAVE_SNPRINTF
> -DHAVE_STDLIB_H -L$ADD_LIB_DIR" CFLAGS="-DHAVE_STDLIB_H -UHAVE_SNPRINTF
> -I$ADD_INC_DIR -I$ADD_INC_DIR/${PLATFORM}" CXXFLAGS="-DHAVE_STDLIB_H
> -UHAVE_SNPRINTF -I$ADD_INC_DIR -I$ADD_INC_DIR -L$ADD_LIB_DIR"
> --build=i386 --host=${HOST} CXX=${CROSS_COMPILE}g++
> CC=${CROSS_COMPILE}gcc AR=${CROSS_COMPILE}ar LD=${CROSS_COMPILE}ld
> RANLIB=${CROSS_COMPILE}ranlib --with-masterdir=/var/cfengine/masterfiles
> --with-inputdir=/var/cfengine/inputs --with-workdir=/var/cfengine
> --libdir=/var/cfengine/lib
>
> Linker fails to resolve the "rpl_" symbols which are actually defined in
> snprintf.c enclosed deep inside conditional compiles. I tried adding a
> few different defines and undefined to CFLAGS, CXXFLAGS and LDFLAGS,
> without much luck so far.

The same define is used both to conditionally compile rpl_fprintf and to
replace occurrences of fprintf with rpl_fprintf, and configure is
supposed to figure this out, so no additional defines should be
necessary. Can you verify that configure outputs:

checking whether snprintf is C99 compliant... no

That being said, it looks like you're not compiling on a native host,
but cross compiling. While this should work in theory, it has been
tested very little (we only cross compile for Windows), so I wouldn't be
surprised if some of the configure tests are not prepared to handle
that. You might have more luck compiling it natively.

Another thing you can try is making the "#include <config.h>" inside
snprintf.c unconditional (remove the #if and #endif).

These are just off the top of my head.

--
Kristian

[Ramakant Duggal]

Hi Kristian,

Thanks for your comments. configure doesn't outout the conclusion to c99 compliance check, when run in debug mode, I see :

+ printf '%s\n' 'configure:19312: checking whether snprintf is C99 compliant'

+ printf %s 'checking whether snprintf is C99 compliant... '

checking whether snprintf is C99 compliant... + false

+ test yes = yes

____________________

native compile is not a possibility for now. Making "#include <config.h>" didn't make a difference. 

If you have any other ideas, I'm more than happy to try. 

Ramakant Duggal Senior Developer   P  M 0422156849   VIXTECHNOLOGY.COM

This email is confidential.  If you have received this email in error please notify us immediately by return email and delete this email and any attachments.  

VIX accepts no liability for any damage caused by this email or any attachments due to viruses, interference, interception, corruption or unauthorised access.

[Ramakant Duggal]

The weird thing is that if I put those 2 funcs outside the deeply-nested conditional compiles, the compiler gives me an error about function already being defined at such line no.

OK, so the compiler can see them but the linker can't.  output of running nm on the generated snprintf.o looks weird :

____________________

$ nm -C ./libcompat/.libs/snprintf.o

         U __cmpdi2

         U __errno_location

         U __fixunsdfdi

         U __floatdidf

00001fc8 T __nldbl_fprintf

00002090 T __nldbl_printf

00002114 T __nldbl_snprintf

00001e90 T __nldbl_vfprintf

00002048 T __nldbl_vprintf

000011b4 T __nldbl_vsnprintf

         U __udivdi3

         U __umoddi3

000006c4 t cast

00000198 t convert

000007e0 t fmtflt

0000027c t fmtint

00000000 t fmtstr

         U free

         U fwrite

00000160 t getnumsep

         U malloc

00000790 t mypow10

00000138 t printsep

00002240 T rpl_asprintf

00002190 T rpl_vasprintf

         U stdout

____________________________________________________

I am a bit lost, as my knowledge of autoconf etc is pretty low, but this might tell you something ?

Cheers

Rama

Ramakant Duggal Senior Developer   P  M 0422156849   VIXTECHNOLOGY.COM

[Kristian Amlie]

On 07/01/16 00:47, Ramakant Duggal wrote:
> The weird thing is that if I put those 2 funcs outside the deeply-nested
> conditional compiles, the compiler gives me an error about function
> already being defined at such line no.
>
> OK, so the compiler can see them but the linker can't. output of
> running nm on the generated snprintf.o looks weird :

Can you check if that file is actually included in the compile at all,
by running "make V=1" and looking at the files that are fed to the
linker. Note that that file is included in the libutils library in the
directory of the same name, and later this is used in libpromises and
cf-agent, so you won't see the file directly in the link command lines
of any of the latter. So the best would probably be:

make clean ; cd libutils ; make V=1

Which should give you the linker command line for libutils.

--
Kristian

[Ramakant Duggal]

I guess you meant libcompat (thats' the one snprintf goes into)

Looks like snprintf.o is included in the linker command.

___________________

libtool: compile:  /opt/crosstool/gcc-4.1.1-glibc-2.5/powerpc-603e-linux-gnu/bin/powerpc-603e-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../libutils -I../libutils -std=gnu99 -pthread -DHAVE_STDLIB_H -I/home/rduggal/jats_cbuilder/rduggal_cfengine_3.6.5.1005.cots_19212/interface/include -I/home/rduggal/jats_cbuilder/rduggal_cfengine_3.6.5.1005.cots_19212/interface/include/PPC_603E -g -Wall -Wno-pointer-sign -Wunused-parameter -O2 -DNDEBUG -DHAVE_STDLIB_H -I/home/rduggal/jats_cbuilder/rduggal_cfengine_3.6.5.1005.cots_19212/interface/include -I/home/rduggal/jats_cbuilder/rduggal_cfengine_3.6.5.1005.cots_19212/interface/include/PPC_603E -MT snprintf.lo -MD -MP -MF .deps/snprintf.Tpo -c snprintf.c

libtool: compile: mv -f "snprintf.o" ".libs/snprintf.o"

mv -f .deps/snprintf.Tpo .deps/snprintf.Plo

bash ../libtool  --tag=CC   --mode=link /opt/crosstool/gcc-4.1.1-glibc-2.5/powerpc-603e-linux-gnu/bin/powerpc-603e-linux-gnu-gcc  -pthread -DHAVE_STDLIB_H -I/home/rduggal/jats_cbuilder/rduggal_cfengine_3.6.5.1005.cots_19212/interface/include -I/home/rduggal/jats_cbuilder/rduggal_cfengine_3.6.5.1005.cots_19212/interface/include/PPC_603E -g -Wall -Wno-pointer-sign -Wunused-parameter -O2 -DNDEBUG -DHAVE_STDLIB_H -I/home/rduggal/jats_cbuilder/rduggal_cfengine_3.6.5.1005.cots_19212/interface/include -I/home/rduggal/jats_cbuilder/rduggal_cfengine_3.6.5.1005.cots_19212/interface/include/PPC_603E  -Bstatic -s -DHAVE_STDLIB_H -L/home/rduggal/jats_cbuilder/rduggal_cfengine_3.6.5.1005.cots_19212/interface/lib/PPC_603E -o libcompat.la  generic_at.lo getopt.lo getopt1.lo strlcat.lo strlcpy.lo memdup.lo closefrom.lo rpl_ctime.lo strrstr.lo snprintf.lo -lnss_nis -ldl -lrt -lm

libtool: link: /opt/crosstool/gcc-4.1.1-glibc-2.5/powerpc-603e-linux-gnu/bin/powerpc-603e-linux-gnu-ar cru .libs/libcompat.a .libs/generic_at.o .libs/getopt.o .libs/getopt1.o .libs/strlcat.o .libs/strlcpy.o .libs/memdup.o .libs/closefrom.o .libs/rpl_ctime.o .libs/strrstr.o .libs/snprintf.o

libtool: link: /opt/crosstool/gcc-4.1.1-glibc-2.5/powerpc-603e-linux-gnu/bin/powerpc-603e-linux-gnu-ranlib .libs/libcompat.a

libtool: link: ( cd ".libs" && rm -f "libcompat.la" && ln -s "../libcompat.la" "libcompat.la" )

_____________________

Again, a symbol table dump for the lnked libconpat.a shows these globals :

____________

nm ./.libs/libcompat.a

.......

snprintf.o:

__________________________

wierdly, it seems to be the case that the 2 functions rpl_fprintf and rpl_printf are being compiled into some sort of mangled names __nldbl_fprintf (and same for printf).

Ramakant Duggal Senior Developer   P  M 0422156849   VIXTECHNOLOGY.COM

[Kristian Amlie]

On 11/01/16 02:29, Ramakant Duggal wrote:
> I guess you meant libcompat (thats' the one snprintf goes into)

Yes, of course, my bad.

> Looks like snprintf.o is included in the linker command.
>

> ...

Yes, everything looks in order there.

Hmm, this goes deep. Can you do a "grep -r nldbl /usr/include" just to
see if you find any reference to what those nldbl macros are supposed to
be doing? I have never seen them before.

Also, there should be a "#define fprintf rpl_fprintf" inside
libutils/config.h. Can you verify this? I suspect that the macro is not
being replaced as it should, and this could lead glibc to apply its own
mangling on the name. Also look out for warnings about "fprintf" being
redefined.

It's often quite hard to anticipate where macro bugs stem from, so
you're likely to have to do some digging. One useful method is to
replace '-o' with '-E' in the gcc command, which causes it to output a
preprocessed file, where all the macros are expanded. Then you can look
and see if fprintf is replaced with rpl_fprintf as it should inside
sprintf.o.

--
Kristian

[Ramakant Duggal]

it comes down to include/sys/cdefs.h :

__________________

#include <bits/wordsize.h>

#if defined __LONG_DOUBLE_MATH_OPTIONAL && defined __NO_LONG_DOUBLE_MATH

# define __LDBL_COMPAT 1

# ifdef __REDIRECT

#  define __LDBL_REDIR1(name, proto, alias) __REDIRECT (name, proto, alias)

#  define __LDBL_REDIR(name, proto) \

  __LDBL_REDIR1 (name, proto, __nldbl_##name)

#  define __LDBL_REDIR1_NTH(name, proto, alias) __REDIRECT_NTH (name, proto, alias)

#  define __LDBL_REDIR_NTH(name, proto) \

  __LDBL_REDIR1_NTH (name, proto, __nldbl_##name)

#  define __LDBL_REDIR1_DECL(name, alias) \

  extern __typeof (name) name __asm (__ASMNAME (#alias));

#  define __LDBL_REDIR_DECL(name) \

  extern __typeof (name) name __asm (__ASMNAME ("__nldbl_" #name));

# endif

#endif

______________________________

Did some googl'ing without finding anything conclusive. It's somehow related to having "no long double" (nldbl) on a processor architecture. I'm this close to just using the previous hack for powerpc where I took the 2 funcs out of the deeply nested conditional compiles

Ramakant Duggal Senior Developer   P  M 0422156849   VIXTECHNOLOGY.COM

[Ramakant Duggal]

preprocessor trail points to include/bits/wordsize.h in the cross compile kit :

___________________

/* Determine the wordsize from the preprocessor defines.  */

#if defined __powerpc64__

# define __WORDSIZE     64

# define __WORDSIZE_COMPAT32    1

#else

# define __WORDSIZE     32

#endif

#if !defined __NO_LONG_DOUBLE_MATH && !defined __LONG_DOUBLE_MATH_OPTIONAL

/* Signal the glibc ABI didn't used to have a `long double'.

   The changes all the `long double' function variants to be redirects

   to the double functions.  */

# define __LONG_DOUBLE_MATH_OPTIONAL   1

# ifndef __LONG_DOUBLE_128__

#  define __NO_LONG_DOUBLE_MATH        1

# endif

#endif

_____________________________________________________

I got it linking by adding "-D__NO_LONG_DOUBLE_MATH" on the configure command line.

Getting this to fit at the autoconf level may not be a simple step for me. Not sure if you or someone in cfengine would like to take that on.

Ramakant Duggal Senior Developer   P  M 0422156849   VIXTECHNOLOGY.COM

[Ramakant Duggal]

sorry about trickle posts.

It's a consequence of the fact that we are building on a 32-bit powerpc platform, which doesn't support 128-bit long doubles natively. I guess teh autoconf scripts will need mods to handle that. 

Not sure if that's got any priorities in your scheme of things. Given a bit more time, I'd look into doing that.

Well at least I got the source tarball building without hack.

Ramakant Duggal Senior Developer   P  M 0422156849   VIXTECHNOLOGY.COM