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

Justin_Hickey_via_RT · November 21, 2003, 5:31am

this bug's URL: http://intevation.de/rt/webrt?serial_num=2232
-------------------------------------------------------------------------

Subject: FreeBSD configure/build issues in 5.7

Platform: other
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: CVS for 5.7 checked out 20031120

When trying to configure grass5.7 under FreeBSD I encountered the following issues:

  1) LOC_CHECK_VERSION lead to an (inconsequential) core dump during configure
  2) the probe for GL didn't work out of the box, needed some help
  3) aclocal.m4 has FreeBSD-specific code that set "SHLIB_LD" in a way that
     caused gcc to exit with an error during the attempt to build datetime.so
  4) include/Make/Shlib.make uses the C compiler as a linker with SHLIB_LD
     as its arguments --- even when SHLIB_LD is fixed up to look like
     gcc arguments instead of a loader this fails, but if the make rule
     is changed to use SHLIB_LD as the loader I was able to get past this
     particular failure.

Here's more details:

  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.

  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.

  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.

-------------------------------------------- Managed by Request Tracker

Glynn_Clements · November 21, 2003, 8:45am

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@virgin.net>

neteler · November 21, 2003, 9:46am

On Fri, Nov 21, 2003 at 08:45:12AM +0000, Glynn Clements wrote:

Request Tracker wrote:

[...]

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

[...]

The basic problem (core of all evil) is that people who don't
know much about Makefile systems (like me) have to solve problems
due to people knowing much about Makefile systems do not want to
join the GRASS 5.7 development...

So far I was unable to find a person to help me with that issues.
Unless somebody helps, it will continue in a "works for me" mode
which currently covers

- GNU/Linux (Mandrake (with RPM), Redhat, etc)
- Mac OSX
- iPAQ/ARM (debian in preparation)
- all of them with static and shared libraries, selectable
with a single flag.

I have no access to FreeBSD and do not intend to study the glory
details of the Makefile system or a potential better implementation
(seems that I already spent some time to get above working).

[... many good recommendations ...]

Maybe another GRASS developer is willing to sort out the 5.7 Makefile
problems so that those uneducated "developers" like me do not have to
waste more time on it. Less talking about it but solving the problem.
I don't ask all the nice other things to do for 5.7, it's simply
a wish for a stable Makefile which makes everybody happy.

Sorry and thanks

Markus