to build python/mapscript on linux amd64, mapserver needs -fPIC

[schut@…]

Building mapserver on amd64 works fine, so does swig-ing for python mapscript.
However, when I try to run `python setup.py build`, I get the following error:

gcc -pthread -shared build/temp.linux-x86_64-2.3/mapscript_wrap.o
build/temp.linux-x86_64-2.3/pygdioctx/pygdioctx.o -L/usr/local/src/mapserver
-L/usr/local/lib -L/usr/lib64 -L. -L/usr/lib -L/lib64 -lgdal -lmap -lfreetype
-lpq -lm -ljpeg -lstdc++ -lgd -lproj -lpdf -lz -lpng -o
build/lib.linux-x86_64-2.3/_mapscript.so
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/usr/local/src/mapserver/libmap.a(maptemplate.o): relocation R_X86_64_32 can not
be used when making a shared object; recompile with -fPIC
/usr/local/src/mapserver/libmap.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1

rebuilding mapserver with -fPIC added to the CFLAGS solves this; the swig
command runs fine then.

Maybe a configure check for x86_64 platform could be added that automaticaly
adds -fPIC to the CFLAGS if on amd64?

[sgillies@…]

will address this for the 4.3 branch.

[dmorissette]

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.

[sgillies@…]

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)

...

[dmorissette]

Adding Frank to the CC. He may have had to deal with that same problem before...
or may know someone who has.

[schut@…]

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 :)

[sgillies@…]

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?

[sgillies@…]

modified configure file

[fwarmerdam]

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. 

[dmorissette]

I like Frank's AC_COMPILER_PIC suggestion, seems like the cleanest uption.

[sgillies@…]

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?

[dmorissette]

configure.in is the authoritative file. "configure" is only in CVS for convenience

[sgillies@…]

How is configure maintained?  Do I run autoconf against configure.in
and then commit the resulting configure?  Do I patch the existing
configure directly?

[dmorissette]

We just run autoconf and commit the resulting configure script. I never thought
a human could patch the configure script directly.  ;)

[fwarmerdam]

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. 

[sgillies@…]

changes committed to configure.in and after

  autoconf configure.in > configure

committed configure.  Changes are in CVS HEAD only.