Open tbonfort opened 12 years ago
Author: sgillies@frii.com Date: 2004/06/30 - 17:01
will address this for the 4.3 branch.
Author: dmorissette Date: 2004/06/30 - 17:32
I wonder if there is a generic way to handle this in the autoconf script so that
all platforms that require -fPIC will get it, and not just amd64.
Author: sgillies@frii.com Date: 2004/06/30 - 18:03
I've looked into the configure.in from other software and it seems that
folks do it platform by platform.
Other than peeking in the configuration of another installed software,
such as Apache, what could we do to detect if -fPIC is needed? I don't
think we should do this because it adds another dependency to mapserver.
I may have been premature in taking ownership ... i don't have an amd64
system so can't test it myself.
I just now looked in Python 2.3.4 configure.in and it looks like they are
adding -fPIC to CCFLAGS and letting cc honor or ignore it. see below:
...
# CCSHARED are the C *flags* used to create objects to go into a shared
# library (module) -- this is only needed for a few systems
AC_MSG_CHECKING(CCSHARED)
if test -z "$CCSHARED"
then
case $ac_sys_system/$ac_sys_release in
SunOS*) if test "$GCC" = yes;
then CCSHARED="-fPIC";
fi;;
hp*|HP*) if test "$GCC" = yes;
then CCSHARED="-fPIC";
else CCSHARED="+z";
fi;;
Linux*|GNU*) CCSHARED="-fPIC";;
BSD/OS*/4*) CCSHARED="-fpic";;
FreeBSD*|NetBSD*|OpenBSD*) CCSHARED="-fPIC";;
OpenUNIX*|UnixWare*)
if test "$GCC" = "yes"
then CCSHARED="-fPIC"
else CCSHARED="-KPIC"
fi;;
SCO_SV*)
if test "$GCC" = "yes"
then CCSHARED="-fPIC"
else CCSHARED="-Kpic -belf"
fi;;
Monterey*) CCSHARED="-G";;
IRIX*/6*) case $CC in
*gcc*) CCSHARED="-shared";;
*) CCSHARED="";;
esac;;
atheos*) CCSHARED="-fPIC";;
esac
fi
AC_MSG_RESULT($CCSHARED)
...
Author: dmorissette Date: 2004/06/30 - 18:20
Adding Frank to the CC. He may have had to deal with that same problem before...
or may know someone who has.
Author: schut@sarvision.com Date: 2004/06/30 - 18:34
Usually I would be willing to help you testing (as I of course do have an amd64
platform) but tomorrow is my last working day before holidays... So tomorrow
(normal working times in the Netherlands, that is :-)) please feel free to ask
me to run some tests if needed (evt. contact me by email personally).
To give you an idea of (my) normal working times here, it's 18:33 now and I were
about to stop 10 minutes ago :)
Author: sgillies@frii.com Date: 2004/09/10 - 16:26
I edited mapserver/configure, adding an -fPIC immediately after the -O2
flag for gcc. Works fine for me on my i686. Am attaching the file to
this issue. Will you try it out and confirm?
-fPIC seems pretty harmless to me ... any objections?
Author: fwarmerdam Date: 2004/09/10 - 17:15
Guys,
Hmm, not sure how I missed this before. Must have gotten buried in
other issues at a busy time of the summer.
I use the following definition for GDAL in my aclocal.m4 file:
AC_DEFUN(AC_COMPILER_PIC,
[
echo 'void f(){}' > conftest.c
if test -z "`${CC-cc} -fPIC -c conftest.c 2>&1`"; then
C_PIC=-fPIC
else
C_PIC=
fi
if test -z "`${CXX-g++} -fPIC -c conftest.c 2>&1`"; then
CXX_PIC=-fPIC
else
CXX_PIC=
fi
rm -f conftest*
AC_SUBST(CXX_PIC,$CXX_PIC)
AC_SUBST(C_PIC,$C_PIC)
])
And invoke it like this in my configure.in file (but only when *not* using
libtool):
AC_COMPILER_PIC
This basically tries using -fPIC and if it doesn't cause a problem
permanently adds it to the compile flags.
It should be safe to add to MapServer as well.
What we have to avoid is adding -fPIC for compilers where it is not a valid
flag. I'm not sure if it is always safe with gcc or not.
Author: dmorissette Date: 2004/09/11 - 00:09
I like Frank's AC_COMPILER_PIC suggestion, seems like the cleanest uption.
Author: sgillies@frii.com Date: 2004/09/11 - 17:29
Turns out that AC_COMPILER_PIC is already in aclocal.m4, and is used to
configure the PHP build. I've edited configure.in to use it and
append to CFLAGS like so:
...
dnl ---------------------------------------------------------------------
dnl Checks for header files.
dnl ---------------------------------------------------------------------
AC_HEADER_STDC
dnl ---------------------------------------------------------------------
dnl Add -fPIC to compiler flags if appropriate
dnl ---------------------------------------------------------------------
AC_COMPILER_PIC
CFLAGS="$CFLAGS $C_PIC"
dnl ---------------------------------------------------------------------
dnl Check for some string functions
dnl ---------------------------------------------------------------------
...
Works fine on my FC2 Linux box. Could result in -fPIC defined twice
but that shouldn't be a problem.
I'm a bit confused about the config stuff ... both configure *and*
configure.in are checked in to CVS? What's up with this? Which one
is the authoritative file?
Author: dmorissette Date: 2004/09/12 - 23:58
configure.in is the authoritative file. "configure" is only in CVS for convenience
Author: sgillies@frii.com Date: 2004/09/13 - 00:13
How is configure maintained? Do I run autoconf against configure.in
and then commit the resulting configure? Do I patch the existing
configure directly?
Author: dmorissette Date: 2004/09/13 - 04:59
We just run autoconf and commit the resulting configure script. I never thought
a human could patch the configure script directly. ;)
Author: fwarmerdam Date: 2004/09/13 - 08:32
Sean,
I believe the configure.in is authoritative, but by having the configure
committed we can let people work from CVS who don't have the right version of
autoconf installed on their system. I have often had problems with packages
that don't commit their configure when it turns out I am running a little
behind the version of autoconf that the maintainer expects.
Author: sgillies@frii.com Date: 2004/09/20 - 19:22
changes committed to configure.in and after
autoconf configure.in > configure
committed configure. Changes are in CVS HEAD only.
Reporter: schut@sarvision.com Date: 2004/06/30 - 16:29