[ expat-Bugs-438876 ] Configure for expat seems to require gcc

noreply@sourceforge.net noreply@sourceforge.net
Fri Dec 7 02:44:02 2001


Bugs item #438876, was opened at 2001-07-05 13:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=110127&aid=438876&group_id=10127

Category: Build control
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: Configure for expat seems to require gcc

Initial Comment:
I was told that expat was a portable, ligthweight XML parser, but I am having
portability issues.  If one uses the GNU gcc compilers on every platform, then
expat seems quite portable.  However, I was surprised to find that the configure
script has no option for selecting a compiler other than gcc.  As an alternative,
I configured without providing any configure options, and then went to hacking
at the Makefiles and the libtool script.  This seems a bad alternative to having
an option to select other compilers in the configure script.  As many other bug
reports have mentioned, the individual trying to install expat using a non-GNU 
C compiler is left to manually change the compile and link options, without a 
clue as to what must be changed.

I have been trying to port to the WorkShop5.0 comilers for Solaris 2.7.  After
hacking compiler options for dependencies, shared object libraries, optimization,
etc., I gave up when 'make' returned the following:

cd lib; gmake
gmake[1]: Entering directory `/home/netlj/Software/expat-1.95.1/lib'
/bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat 
-DVERSION=expat_1.95.1 -I. -I..  -g -xO2 -c xmlparse.c
mkdir .libs
cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.1\ -I. -I.. -g -xO2 -c 
xmlparse.c  -KPIC -DPIC -o .libs/xmlparse.lo
cc: illegal suffix of output filename
gmake[1]: *** [xmlparse.lo] Error 1
gmake[1]: Leaving directory `/home/netlj/Software/expat-1.95.1/lib'
gmake: *** [lib] Error 2

Since I don't understand what the .lo file is for, I'm not sure how to proceed to 
resolve this problem.

I'd like to request that you generalize your configure script to allow the user to 
specify a C compiler other than gcc.  If the user is restricted to gcc or a fair amount
of hacking, they may look elsewhere for a XML parser.



----------------------------------------------------------------------

>Comment By: Greg Stein (gstein)
Date: 2001-12-07 02:43

Message:
Logged In: YES 
user_id=6501

Selection of a compiler, flags, etc, are all part of the GNU
configure process. In fact, with recent versions of autoconf
(and the resulting configure script), just entering
"./configure --help" will present help information about
setting the compiler and CFLAGS.

I'm closing this bug as fixed by virtue of our config/build
cleanup. I would also recommend that the packager (fdrake
currently) upgrade to autoconf 2.5x and libtool 1.4 for
their improvements.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-12-06 00:13

Message:
Logged In: NO 

I am building expat 1.95.2 on Solaris 7 with Sun WorkShop
5.0.
I do have a small problem that I'll document in another bug
report,
but there's no such issue with expat 1.95.2 anymore, if
there ever
was one with expat 1.95.1.

That said, maybe the README file could have a sentence like
"to build with a compiler other than the default (GCC) use
CC=cc
and CFLAGS=<whatever>."


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-24 20:22

Message:
Logged In: YES 
user_id=3066

Looking at this again, I suspect this is still a possible problem.  This probably represents some non-portability in the libtool tool.  Can anyone confirm this, or offer a fix?

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-20 20:54

Message:
Logged In: YES 
user_id=3066

I think all the gcc dependencies have been removed from the current development version in CVS.  Can anyone with this compiler and not GCC check this to see if the problem persists?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=110127&aid=438876&group_id=10127