[GRASS5] [bug #2232] (grass) FreeBSD configure/build issues in 5.7

Glynn Clements glynn.clements at virgin.net
Fri Nov 21 03:45:12 EST 2003


Request Tracker wrote:

>   1) LOC_CHECK_VERSION tries to check PROJ4's version in two ways, first by
>       trying to fputs(PJ_VERSION,fp), then using an fprintf.  The first causes
>       a segfault on FreeBSD.  Seeing this segfault caused me to go down 
>       several blind alleys looking for a problem, where there was none -- 
>       the second try actually found the version just fine.

The change to aclocal.m4 has also been made to 5.0 (which doesn't use
it) and 5.3 (which does).

Personally, I think that it's the wrong approach; it would be
preferable to have separate LOC_CHECK_VERSION_STRING and
LOC_CHECK_VERSION_INT macros.

>   2) The probe for GL tries to build with -lpthread if -lGL didn't link.
>      Turns out that on FreeBSD the way to get pthreads is to include -pthread
>      in CFLAGS.  There's code in aclocal.m4 that puts -pthread into 
>      EXTRA_CFLAGS, but this isn't used inside configure for any probes.  I 
>      had to use CFLAGS="-pthread" in the configure line.

This will also be true for 5.0/5.3.

But do you actually need that switch? What happens without it? NVIZ
itself doesn't actually use pthreads; the second check is because some
Linux libGL implementations use libpthread but don't list it as a
dependency.

>   3) Here's a big one:  in the FreeBSD specific code in aclocal.m4, SHLIB_LD
>      is set to "ld -Bshareable -x", and then in include/Make/Shlib.make 
>      SHLIB_LD is used in a $(CC) line as extra flags.  Since "-x" is the 
>      gcc option used to specify alternate languages, the build dies with a
>      complaint "unrecognized language ..../between.o".  A more correct
>      SHLIB_LD would be "-Wl,-Bshareable,-x" if it were to be used as arguments 
>      for $(CC)... but more on that later
> 
>      Reading through the aclocal.m4, there seems to be an inconsistency in how
>      SHLIB_LD is set.  In some cases (as in the various BSDs) it looks like 
>      it's meant to be used as the program to run (with options) to get 
>      shared libraries, and in others it appears to be intended as extra flags 
>      for $(CC).
> 
>   4) After tweaking configure so that SHLIB_LD was "-Wl,-Bshareable,-x",
>      the attempt to build libgrass_datetime.so dies with a complaint about an
>      undefined reference to "main":
>      The exact command that's dying is:
> 
> gcc -export-dynamic -L/users/russo/src/grass_experimental/grass57_exp_2003_11_15/dist.i386-unknown-freebsd4.8/lib   -rpath  -Wl,-Bshareable,-x    \
>         OBJ.i386-unknown-freebsd4.8/between.o \
> OBJ.i386-unknown-freebsd4.8/copy.o OBJ.i386-unknown-freebsd4.8/same.o \
> OBJ.i386-unknown-freebsd4.8/diff.o OBJ.i386-unknown-freebsd4.8/error.o \
> OBJ.i386-unknown-freebsd4.8/format.o OBJ.i386-unknown-freebsd4.8/incr1.o \
> OBJ.i386-unknown-freebsd4.8/incr2.o OBJ.i386-unknown-freebsd4.8/incr3.o \
> OBJ.i386-unknown-freebsd4.8/local.o OBJ.i386-unknown-freebsd4.8/misc.o \
> OBJ.i386-unknown-freebsd4.8/change.o OBJ.i386-unknown-freebsd4.8/scan.o \
> OBJ.i386-unknown-freebsd4.8/sign.o OBJ.i386-unknown-freebsd4.8/type.o \
> OBJ.i386-unknown-freebsd4.8/tz1.o OBJ.i386-unknown-freebsd4.8/tz2.o \
> OBJ.i386-unknown-freebsd4.8/values.o  -o \
> /users/russo/src/grass_experimental/grass57_exp_2003_11_15/dist.i386-unknown-freebsd4.8/lib/libgrass_datetime.so
> 
> which results in
> /usr/lib/crt1.o: In function `_start':
> /usr/lib/crt1.o(.text+0x82): undefined reference to `main'
> 
> It appears that this problem is due to the use of $(CC) ... 
> $(SHLIB_LD) as the shared-library linker. gcc is trying to link an
> executable, not a shared library.
> 
> When I edited include/Make/Shlib.make to use $(SHLIB_LD) instead of
> $(CC)...$(SHLIB_LD), and returned SHLIB_LD to the "ld -Bshareable -x"
> it had been initially, I was able to get farther along in the build. 
> I've not yet been successful in getting the whole thing built (I'm
> currently stuck during a link phase), but these issues took a long
> time to get past.

Whoever ripped SC_CONFIG_CFLAGS appears to have completely changed the
semantics of $(SHLIB_LD), but only for a few specific platforms. In
most cases, it's the complete command to link a shared library, but in
a few cases it's just the switches. Shlib.make assumes that it's just
the switches. FWIW, $(STLIB_LD) is always the complete command, and
the comments say:

#       STLIB_LD -      Base command to use for combining object files
#                       into a static library.

#       SHLIB_LD -      Base command to use for combining object files
#                       into a shared library.

Note that this hasn't changed since SC_CONFIG_FLAG was introduced in:

	revision 1.3
	date: 2003/08/05 16:13:16;  author: markus;  state: Exp;  lines: +1178 -0
	tried to improve Makefile system to also support MacOSX (maybe also helps for IRIX etc). Hope it doesn't break anything

IOW, the code which Paul used appears to have been broken to start
with. Or maybe it needs some other bits which were omitted (it's
conceivable that the program could be prepended automatically if
$(SHLIB_LD) starts with a dash).

Aside: I think that there should really be a separate $(LD) variable
for the linker (for linking executables), rather than assuming that
the C compiler is also the the linker (whilst this is normally true, I
see no reason to force the case unnecessarily).

Unfortunately, the use of $(CC) as a linker is hardwired into autoconf
(AC_TRY_LINK uses ${CC-cc}, ${CXX-g++} or ${F77-f77} depending upon
the current language), so we'll probably just end up with:

	CC		= @CC@
	LD		= @CC@

in Platform.make.in, but we should at least make the distinction
within the Makefiles and include/Make/*.make.

-- 
Glynn Clements <glynn.clements at virgin.net>




More information about the grass-dev mailing list