134363 - configure.in has unnecessary C++ tests that trigger an autoconf bug

Status: NEW

(Directory :: LDAP C SDK, defect)

Description

[(not reading, please use [e-mail] instead)]

Here's what's going on.

mozilla/directory/c-sdk/configure

has:

if test -n "$ac_declaration"; then
 echo '#ifdef __cplusplus' >>confdefs.h
 echo $ac_declaration      >>confdefs.h
 echo '#endif'             >>confdefs.h
fi

(there are two occurances of this) 
I'm sure there's something in configure.in that creates that, too.

That puts the offending lines into confdefs.h, and then, see the end of 
configure:

# Transform confdefs.h into DEFS.
# Protect against shell expansion while executing Makefile rules.
# Protect against Makefile macro expansion.
cat > conftest.defs <<\EOF
s%#define \([A-Za-z_][A-Za-z0-9_]*\) *\(.*\)%-D\1=\2%g
s%[     `~#$^&*(){}\\|;'"<>?]%\\&%g
s%\[%\\&%g
s%\]%\\&%g
s%\$%$$%g
EOF
DEFS=`sed -f conftest.defs confdefs.h | tr '\012' ' '`
rm -f conftest.defs

and DEFS is used in mozilla/directory/c-sdk/config/autoconfig.mk

and that makes it show up here:

gcc -o now.o -c     -Wall -pthreads -O -fPIC  -UDEBUG  -DMOZILLA_CLIENT=1 -
DNDEBUG=1 #ifdef\ __cplusplus void\ exit\ \(int\)\; #endif -DXP_UNIX=1 -
DSVR4=1 -DSYSV=1 -D__svr4=1 -D__svr4__=1 -DSOLARIS=1 -
DHAVE_FCNTL_FILE_LOCKING=1 -D_PR_HAVE_OFF64_T=1 -D_LARGEFILE64_SOURCE=1 -
DHAVE_LCHOWN=1 -DHAVE_STRERROR=1 -D_REENTRANT=1 -DHAVE_POINTER_LOCALTIME_R=1  -
DFORCE_PR_LOG -D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM   now.c

I don't know enough about configure and configure.in to say if we should remove 
those lines from configure or not.

Comment 1

[(not reading, please use [e-mail] instead)]

over to dmose.

cls has a fix for this, and will follow up with a brain dump of what he figure 
out and what he did to fix it.

he'll also follow up with a suggestion on we should do next about it.

Comment 2

[hacker formerly known as [e-mail]]

I tracked the snippet to autoconf 2.13-14's acspecific.m4 file in the
AC_PROG_CXX_EXIT_DECLARATION macro. This macro is used by AC_PROG_CXX.  I don't
know why this doesn't cause a problem on other platforms as it adds that code
snippet directly to confdefs.h which is used to populate @DEFS@.  Looking at
RH6.2's autoconf 2.13, it doesn't have that CXX_EXIT macro nor that code snippet
anywhere.  

On one hand, we have to ask why we are doing C++ checks for ldap since it's all
in C.  On the other hand, this is definitely a RedHat regression as the stock
2.13 doesn't have this bug.  In fact, looking at the changelog, this feature was
a backport from the 2.5x series that we don't support at all.

* Tue Jun 26 2001 Jens Petersen <[e-mail]>

- Add a back-port of _AC_PROG_CXX_EXIT_DECLARATION
  from version 2.50 to make detection of C++ exit()
  declaration prototype platform independent.  The check is
  done in AC_PROG_CXX with the result stored in "confdefs.h".
  The exit() prototype in AC_TRY_RUN_NATIVE is no longer needed.


I've filed a bug on RedHat about this,
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62361 .

Comment 3

[(not reading, please use [e-mail] instead)]

I'm pleased to report the cls's change (to use a configure built on rh 6.2) has 
fixed the problem and turned speedracer green.

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: patch to remove C++ related constructs from configure.in, v1

Patch to get rid of all CXX-related cruft from configure.in.  I haven't
actually tested to see if this fixes the Solaris problem, but it ought to.

Comment 5

[cls]

I was updating this patch when I ran across http://lxr.mozilla.org/seamonkey/source/directory/c-sdk/build.mk#433 .  Is that comment still accurate?  On the LDAP trunk, there's also the USE_CCC_TO_LINK variable and corresponding ifdefs.  Removing the C++ checks may be a lost cause.

Comment 6

[Mark Smith [:mcs]]

(In reply to comment #5)
> I was updating this patch when I ran across
> http://lxr.mozilla.org/seamonkey/source/directory/c-sdk/build.mk#433 .  Is that
> comment still accurate?  On the LDAP trunk, there's also the USE_CCC_TO_LINK
> variable and corresponding ifdefs.  Removing the C++ checks may be a lost
> cause.

Historically, on some platforms linking with the C++ compiler solved various problems.  Unfortunately I don't remember what the problems were exactly.  I added Rich Megginson to the bug CC to see if his memory is better than mine.

Comment 7

[Rich Megginson]

It's probably not necessary anymore, with modern compilers.  However, this may still be a problem on HP/ux PA-RISC machines - we always had weird linking problems with cc vs. aCC.

Comment 8

[Rich Megginson]

The command line tools (ldapsearch, et. al.) do have some C++ code in them to handle the native->utf8 charset conversion.  So we do need a C++ compiler.  In addition, on some platforms you have to use the C++ command to run the linker so it can do the right C++ library mojo.  So I guess what I'm saying is that I'd rather fix configure to do the correct C++ tests.

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

Rich: that sounds like a reasonable plan also.  Reassigning this bug to the default owner, as this isn't anything I'll be able to get to anytime soon.

Comment 10

[Rich Megginson]

Mark, please reassign this to me.