Details Ticket 2232


Comment | Reply | Take | Open


Serial Number 2232
Subject FreeBSD configure/build issues in 5.7
Area grass5.7
Queue grass
Requestors russo@bogoflux.losalamos.nm.us
Owner none
Status resolved
Last User Contact Wed Mar 24 11:53:22 2004 (4 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Wed Mar 24 11:53:26 2004 (4 yr ago)
Created Fri Nov 21 06:31:37 2003 (5 yr ago)

Transaction History Ticket 2232


Fri, Nov 21 2003 06:31:37    Request created by guest  
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-f
reebsd4.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.
Fri, Nov 21 2003 06:49:59    Comments added by guest  
Oh yes, one other thing (it's me, the original submitter):

The Grass 5.7 makefiles appear to assume one is running GNU make, and that
"make" is GNU make.  But the makefiles don't use $(MAKE) uniformly, so on a 
system where "make" is Pmake and "gmake" is GNU make (such as FreeBSD) it 
becomes difficult to build without kludging a symlink into your path.

(see for example the top level makefile, where the default target does a 
        for subdir in $$list; do \
                (cd $$subdir && make) || exit 1; \ 
          [...]

The "make" should probably be "$(MAKE)" so that one could force use of "gmake"
with "gmake MAKE=gmake" or some such.)



Fri, Nov 21 2003 07:22:14    Comments added by guest  
(me again, original submitter)

I found another thing in aclocal.m4 that caused a link problem (much) later in
the build.  During the FreeBSD-specific setup in aclocal.m4, LDFLAGS is
unceremoniously overwritten with "-export-dynamic" -- rendering it difficult
to force the "-L/usr/local/lib" that FreeBSD tends to need.  I had tried to
get it there during configure by specifying 

LDFLAGS="-L/usr/local/lib" ./configure ....

That wasn't enough, because libproj wasn't found until I also added
LIBS="-L/usr/local/lib" to the configure.

But when I built, well into the game it tried to link with -lintl, and only
then did I find that LDFLAGS had been clobbered, as libintl is in
/usr/local/lib and the -L I'd put into LDFLAGS was missing.

I got around this by changing the relevant line in configure
to 
  LDFLAGS="-export-dynamic $LDFLAGS"
so that configure-line settings of LDFLAGS wouldn't go away.

I'm not declaring victory yet (I just hit another link error :-( ), but I'm
much farther along than before.  In summary, I had to do the following to make
grass5.7 build on FreeBSD:

  1) Change the file include/Make/Shlib.make so that the make rule read:

   $(SHLIB): $(SHLIB_OBJS)
       $(SHLIB_LD) $(LDFLAGS) $(LD_SEARCH_FLAGS) $(EXTRA_LIBDIRS) $(LIBDIRS)
\
       $(TOOLS_LIBDIRS) $(SHLIB_OBJS) $(EXTRA_LIBS) -o $@

   Naturally this will require a change in the definition of SHLIB_LD for
   platforms other than FreeBSD.

  2) I had to change 
     LDFLAGS="-export-dynamic"
     to
     LDFLAGS="-export-dynamic $LDFLAGS"
     in aclocal.m4 (actually I did it in configure rather than have to rebuild
using autoconf)

  3) I had to configure with:
  LDFLAGS="-L/usr/local/lib" CPPFLAGS="-I/usr/local/include
-I/usr/local/include/freetype2" CFLAGS="-pthread" ./configure
--with-grass50=/users/russo/src/grass_experimental/grass53_exp_2003_11_15
--prefix=/users/russso/grass57
--with-tcltk-includes="/usr/local/include/tcl8.3 /usr/local/include/tk8.3"
--with-tcltk-libs="/usr/local/lib/tcl8.3 /usr/local/lib/tk8.3"
--with-opengl-include=/usr/X11R6/include/ --with-opengl-libs=/usr/X11R6/lib
--with-freetype=yes

   to accomodate all the special places things wind up when installed via
   the FreeBSD ports system and to get "-pthread" in the right place during 
the configure.
Fri, Nov 21 2003 08:34:25    Comments added by guest  
Last one tonight, I *promise*.

In addition to all the other stuff above, I discovered this:

  LD_SEARCH_FLAGS='-rpath ${LIB_RUNTIME_DIR}'

among the aclocal.m4 freebsd-specific stuff.  Turns out that LIB_RUNTIME_DIR
is never defined anywhere, so at make time LD_SEARCH_FLAGS is just "-rpath".
This leads the linker to think that the first object file in every link it
does is just an additional search path, not an object to add.  I didn't quite
know what to do here, so I just defined LIB_RUNTIME_DIR to be the lib
directory that was getting created by the build:
  LIB_RUNTIME_DIR=.../dist.i386-unknown-freebsd4.8/lib make

This got me much farther until I hit an undefined reference to cuserid --- in
FreeBSD this is considered an obsolete function requiring "-lcompat," so it
was back to configure for this boy, adding "LIBS=-lcompat" to the configure
line.  But the error is in 

gcc -export-dynamic -L/usr/local/lib 
-L/users/russo/src/grass_experimental/grass57_exp_2003_11_15/dist.i386-unknown-freebsd4.8/lib
-o
/users/russo/src/grass_experimental/grass57_exp_2003_11_15/dist.i386-unknown-freebsd4.8/etc/form/for
m
OBJ.i386-unknown-freebsd4.8/form.o -lgrass_dbmiclient -lgrass_dbmibase
-lgrass_gis -lgrass_datetime  -lintl -lgrass_datetime \
                        -L/usr/local/lib/tcl8.3 -L/usr/local/lib/tk8.3 -ltk83
-lm  -ltcl83 -lm -lm  -lz 
/users/russo/src/grass_experimental/grass57_exp_2003_11_15/dist.i386-unknown-fre
ebsd4.8/lib/libgrass_dbmibase.so: undefined reference to `cuserid'

It appears that $(LIBS) is not used in the lib/form Makefile, so there's no
easy way to kludge this to force -lcompat to be linked in, short of hacking on
the makefile directly.  I tried hacking $(LIBS) into the end of the link line
in lib/form/Makefile, but it appears that LIBS isn't getting passed to that
makefile or something, because -lcompat isn't there even though I set LIBS to
have it when I configured.  Doing the wrong thing, adding -lcompat directly to
the Makefile for lib/form as an experimental kludge, did indeed get me past
the form problem.  I got stuck in exactly the same way on db/drivers/dbf,
which also uses cuserid and for which I'd have to kludge the makefile as well.
I apologize if this long sequence of ramblings appears to be a complaint -- it
is not.  I am well aware that grass5.7 is not a production release, and I'm
trying to document the troubles I had getting it to build under freebsd so
that they can get fixed. 

So one last summary and then I go to bed:
  1) SHLIB_LD and the use thereof in include/Make/Shlib.make are not correct
for FreeBSD.
     Perhaps the best, most portable approach is to use "SHLIB_LD" as the 
     program to use for linking shared libraries, and on those platforms for
which the current Shlib.make works properly that variable can be set to 
     "$(CC)".  Shlib.make can be changed to use "$(SHLIB_LD)" as the program,
and what is currently put into SHLIB_LD for working platforms could be 
     put into SHLIB_LD_FLAGS.  For FreeBSD, then, SHLIB_LD would be "ld"
     and the SHLIB_LD_FLAGS could be "-Bshareable -x".
  2) LDFLAGS is getting clobbered so one can't use that variable on
     the configure line to force -L/usr/local/lib into the linker search 
     path.  This can easily be fixed just by adding "-L/usr/local/lib" to 
     FreeBSD's LDFLAGS anyway --- it'll always be needed, as will  
     "-I/usr/local/include" in CPPFLAGS.  As long as there are platform 
     specific things in configure, might as well put all the platform specific
stuff that's needed
  3) The configure script does a part-way job of putting -pthread into 
     EXTRA_CFLAGS, without actually putting it in CFLAGS where it'll be needed
during the configure (and probably during the build).
  4) The use of cuserid is deprecated on FreeBSD, but if it is used one must
include -lcompat.  This is probably best addressed by adding an
     AC_SEARCH_LIBS call in configure, looking to see if cuserid can be 
     found with no library added, or if -lcompat is needed.  
       AC_SEARCH_LIBS(cuserid,compat)
     would probably do the trick --- it would say "none needed" on the 
     platforms that currently work just fine, and would search -lcompat
     on FreeBSD and be happy
  5) The modules that use cuserid need to link in the things that configure
has probed for (in my case, -lcompat).

All this, three hours later and I don't yet have a binary --- but I'll keep
trying and feeding back my results.
Fri, Nov 21 2003 09:45:55    Mail sent by glynn.clements@virgin.net  
Return-Path <glynn.clements@virgin.net>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn.clements@virgin.net>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <16317.53400.91799.832410@cerise.nosuchdomain.co.uk>
Date Fri, 21 Nov 2003 08:45:12 +0000
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #2232] (grass) FreeBSD configure/build issues in 5.7
In-Reply-To <20031121053137.D41C613B91@lists.intevation.de>
References <20031121053137.D41C613B91@lists.intevation.de>
X-Mailer VM 7.07 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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/libgra
ss_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>


Fri, Nov 21 2003 10:35:46    Mail sent by russo@bogoflux.losalamos.nm.us  
Return-Path <russo@bogoflux.losalamos.nm.us>
Delivered-To grass-bugs@lists.intevation.de
Date Fri, 21 Nov 2003 02:34:57 -0700
From Tom Russo <russo@bogoflux.losalamos.nm.us>
To Glynn Clements via RT <grass-bugs@intevation.de>
Subject Re: [bug #2232] (grass) Transaction (glynn.clements@virgin.net)
Message-ID <20031121093457.GA25401@bogoflux.losalamos.nm.us>
References <20031121084556.141E713B91@lists.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20031121084556.141E713B91@lists.intevation.de>
User-Agent Mutt/1.4i
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
On Fri, Nov 21, 2003 at 09:45:56AM +0100, a Mr. Richard Feyler of Fort Lee, New
Jersey <grass-bugs@intevation.de> writes 'Dear Rosanne Rosannadanna':
> 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.

I agree with that --- since you know at the time of writing configure.in
what format PROJ's version #define is, it doesn't make sense to try the
fputs and ignore the segfault.

> >   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.

libGL on FreeBSD (actually from Mesa) will not link with the test program
unless -pthread is included --- leaving it off leads to undefined externals 
("pthread_xxxxxxx") and consequent claim by configure that libGL isn't found.
That's probably because the Mesa implementation is the same one as the 
"some Linux libGL implementations" you refer to.

> 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. 
 
Nod, that's what I saw.  Unfortunately I was unable to figure out a proper
set of switches that could get this thing built without changing the
semantics of SHLIB_LD back to "the program" and frobbing the Shlib.make 
file.  It wasn't a clean fix, but it did allow the build to proceed.

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://www.qsl.net/~km5vy/
 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]
Fri, Nov 21 2003 10:46:34    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Fri, 21 Nov 2003 10:46:22 +0100
From Markus Neteler <neteler@itc.it>
To Glynn Clements <glynn.clements@virgin.net>
Cc Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #2232] (grass) FreeBSD configure/build issues in 5.7
Message-ID <20031121104622.A25009@itc.it>
Mail-Followup-To Glynn Clements <glynn.clements@virgin.net>, Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
References <20031121053137.D41C613B91@lists.intevation.de> <16317.53400.91799.832410@cerise.nosuchdomain.co.uk>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5.1i
In-Reply-To <16317.53400.91799.832410@cerise.nosuchdomain.co.uk>; from glynn.clements@virgin.net on Fri, Nov 21, 2003 at 08:45:12AM +0000
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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


Fri, Nov 21 2003 22:07:55    Mail sent by russo@bogoflux.losalamos.nm.us  
Return-Path <russo@bogoflux.losalamos.nm.us>
Delivered-To grass-bugs@lists.intevation.de
Date Fri, 21 Nov 2003 14:07:14 -0700
From Tom Russo <russo@bogoflux.losalamos.nm.us>
To Markus Neteler via RT <grass-bugs@intevation.de>
Subject Re: [bug #2232] (grass) FreeBSD configure/build issues in 5.7
Message-ID <20031121210714.GC3743@bogoflux.losalamos.nm.us>
References <20031121094634.4984813BBB@lists.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20031121094634.4984813BBB@lists.intevation.de>
User-Agent Mutt/1.4i
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00, UPPERCASE_25_50
X-Spam-Level
On Fri, Nov 21, 2003 at 10:46:34AM +0100, a Mr. Richard Feyler of Fort Lee, New
Jersey <grass-bugs@intevation.de> writes 'Dear Rosanne Rosannadanna':
> 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.
[...]
> 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.

Unfortunately, I am unable to extend a competant hand to help fix the
Grass makefile system in general.  The structure of Grass is just too
big for me to tackle in my spare time between 4 and 5 in the morning,
and I have access to very few platforms on which to verify my changes
would be universally appropriate.

However, in the spirit of "it works for me" I did manage to do what I
think is a safe job of hacking on the makefiles and associated
includes and autoconfiscation to get Grass 5.7 building as easily as
5.0 ever did (I've been using 5.0 since "beta 3").

The following very simple context diffs against the 5.7 CVS repository
fix the build on FreeBSD, enabling all the shared library issues to be
worked out with a minimal impact on the structure of the Grass
makefiles.  To configure on FreeBSD after these patches were applies 
required only:

 CPPFLAGS="-I/usr/local/include/freetype2" ./configure \ 
 --with-grass50=/path/to/grass/sources \
  --with-tcltk-includes="/usr/local/include/tcl8.3 /usr/local/include/tk8.3"
\
  --with-tcltk-libs="/usr/local/lib/tcl8.3 /usr/local/lib/tk8.3" \
  --with-freetype=yes

The only reason it was *that* long is because the FreeBSD ports
collection doesn't dump things into /usr/include and /usr/lib the way
some linux distributions do.

I believe, but cannot verify, that none of these changes will have any
effect whatsoever on platforms that already work with the Grass 5.7 build
system, and so I believe they are safe to apply to the repository.

Naturally, the changes to aclocal.m4 and configure.in will require an
autoreconf to get configure rebuilt.  I have tested the rebuilt
configure script, but the patch for configure is monstrously long and
I don't want to attach it.

My patches with interspersed commentary follow.

This one fixes broken stuff in the FreeBSD block of aclocal.m4
It should have absolutely no effect on any other platform.

Index: aclocal.m4
===================================================================
RCS file: /home/grass/grassrepository/grass51/aclocal.m4,v
retrieving revision 1.11
diff -c -r1.11 aclocal.m4
*** aclocal.m4	17 Nov 2003 16:00:25 -0000	1.11
--- aclocal.m4	21 Nov 2003 20:46:15 -0000
***************
*** 894,907 ****
  	FreeBSD-*)
  	    # FreeBSD 3.* and greater have ELF.
  	    SHLIB_CFLAGS="-fPIC"
! 	    SHLIB_LD="ld -Bshareable -x"
  	    SHLIB_LD_LIBS='${LIBS}'
  	    SHLIB_SUFFIX="so"
  	    DL_OBJS=""
  	    DL_LIBS=""
- 	    LDFLAGS="-export-dynamic"
  	    CC_SEARCH_FLAGS='-Wl,-rpath,${LIB_RUNTIME_DIR}'
  	    LD_SEARCH_FLAGS='-rpath ${LIB_RUNTIME_DIR}'
  	    if test "${GRASS_THREADS}" = "1" ; then
  		# The -pthread needs to go in the CFLAGS, not LIBS
  		LIBS=`echo $LIBS | sed s/-pthread//`
--- 894,911 ----
  	FreeBSD-*)
  	    # FreeBSD 3.* and greater have ELF.
  	    SHLIB_CFLAGS="-fPIC"
! 	    SHLIB_LD="-shared"
  	    SHLIB_LD_LIBS='${LIBS}'
  	    SHLIB_SUFFIX="so"
  	    DL_OBJS=""
  	    DL_LIBS=""
  	    CC_SEARCH_FLAGS='-Wl,-rpath,${LIB_RUNTIME_DIR}'
  	    LD_SEARCH_FLAGS='-rpath ${LIB_RUNTIME_DIR}'
+               # this is where most installed packages go
+ 	    CPPFLAGS="$CPPFLAGS -I/usr/local/include"
+     	    LDFLAGS="$LDFLAGS -L/usr/local/lib"
+               # require this for GL probe to work
+ 	    CFLAGS="$CFLAGS -pthread"
  	    if test "${GRASS_THREADS}" = "1" ; then
  		# The -pthread needs to go in the CFLAGS, not LIBS
  		LIBS=`echo $LIBS | sed s/-pthread//`

This adds a search for extra libraries needed to find "cuserid" and 
puts them in a substitution variable called "DBMIEXTRALIB" --- the 
dbmi_base library is the only one that uses cuserid.  On a platform that
requires no extra library this will have no effect at all.

Index: configure.in
===================================================================
RCS file: /home/grass/grassrepository/grass51/configure.in,v
retrieving revision 1.39
diff -c -r1.39 configure.in
*** configure.in	17 Nov 2003 16:00:24 -0000	1.39
--- configure.in	21 Nov 2003 20:46:43 -0000
***************
*** 451,456 ****
--- 451,465 ----
  ])])])
  AC_SUBST(COMPATLIB)
  
+ # Note that some systems (FreeBSD for example) need an extra library for
+ # cuserid
+ ac_save_libs="$LIBS"
+ LIBS=""
+ AC_SEARCH_LIBS(cuserid,[compat])
+ DBMIEXTRALIB=$LIBS
+ LIBS=$ac_save_libs
+ AC_SUBST(DBMIEXTRALIB)
+ 
  AC_CHECK_FUNC(xdrmem_create, XDRLIB=, [
  AC_CHECK_LIB(sun, xdrmem_create, XDRLIB=-lsun, [
  AC_CHECK_LIB(nsl, xdrmem_create, XDRLIB=-lnsl, [

These patches propagate the DBMIEXTRALIB variable down to all of the
makefiles that use DBMIBASE through the "DBMILIB" variable.  If the
DBMIEXTRALIB variable is empty this should have no effect on any other
platform.

Index: include/Make/Grass.make.in
===================================================================
RCS file: /home/grass/grassrepository/grass51/include/Make/Grass.make.in,v
retrieving revision 1.31
diff -c -r1.31 Grass.make.in
*** include/Make/Grass.make.in	23 Sep 2003 08:54:42 -0000	1.31
--- include/Make/Grass.make.in	21 Nov 2003 20:46:47 -0000
***************
*** 195,201 ****
  DBMIBASELIB     = -l$(DBMIBASE_LIBNAME)
  DBMICLIENTLIB   = -l$(DBMICLIENT_LIBNAME)
  DBMIDRIVERLIB   = -l$(DBMIDRIVER_LIBNAME)
! DBMILIB         = $(DBMICLIENTLIB) $(DBMIBASELIB)
  SQLPLIB     = -l$(SQLP_LIBNAME)
  DBSTUBSLIB  = -l$(DBSTUBS_LIBNAME)
  
--- 195,201 ----
  DBMIBASELIB     = -l$(DBMIBASE_LIBNAME)
  DBMICLIENTLIB   = -l$(DBMICLIENT_LIBNAME)
  DBMIDRIVERLIB   = -l$(DBMIDRIVER_LIBNAME)
! DBMILIB         = $(DBMICLIENTLIB) $(DBMIBASELIB) $(DBMIEXTRALIB)
  SQLPLIB     = -l$(SQLP_LIBNAME)
  DBSTUBSLIB  = -l$(DBSTUBS_LIBNAME)
  
Index: include/Make/Platform.make.in
===================================================================
RCS file: /home/grass/grassrepository/grass51/include/Make/Platform.make.in,v
retrieving revision 1.17
diff -c -r1.17 Platform.make.in
*** include/Make/Platform.make.in	10 Nov 2003 14:43:00 -0000	1.17
--- include/Make/Platform.make.in	21 Nov 2003 20:46:47 -0000
***************
*** 102,107 ****
--- 102,108 ----
  DBMINCPATH          = @DBMINCPATH@
  DBMLIBPATH          = @DBMLIBPATH@
  DBMLIB              = @DBMLIB@
+ DBMIEXTRALIB        = @DBMIEXTRALIB@
  
  #readline
  READLINEINCPATH     = @READLINEINCPATH@

And the remaining patches get DBMIEXTRALIB into the three packages
that get dbmi_base only through the DBMIBASELIB variable.  Again, if
the DBMIEXTRALIB comes back empty from configure, this will have no
effect.
 
Index: db/drivers/dbf/Makefile
===================================================================
RCS file: /home/grass/grassrepository/grass51/db/drivers/dbf/Makefile,v
retrieving revision 1.6
diff -c -r1.6 Makefile
*** db/drivers/dbf/Makefile	22 May 2003 14:02:08 -0000	1.6
--- db/drivers/dbf/Makefile	21 Nov 2003 20:46:47 -0000
***************
*** 9,15 ****
  SHPDRIVER=$(DBDRIVERDIR)/shp
  DEPENDENCIES = $(GISDEP)
  
! LIBES = $(DBMIDRIVERLIB) $(DBMIBASELIB) $(SQLPLIB) $(SHAPELIB) $(DBSTUBSLIB)
$(GISLIB) $(DATETIMELIB)
  
  OBJS 	=  \
  	column.o \
--- 9,15 ----
  SHPDRIVER=$(DBDRIVERDIR)/shp
  DEPENDENCIES = $(GISDEP)
  
! LIBES = $(DBMIDRIVERLIB) $(DBMIBASELIB) $(DBMIEXTRALIB) $(SQLPLIB) $(SHAPELIB)
$(DBSTUBSLIB) $(GISLIB) $(DATETIMELIB)
  
  OBJS 	=  \
  	column.o \
Index: db/drivers/odbc/Makefile
===================================================================
RCS file: /home/grass/grassrepository/grass51/db/drivers/odbc/Makefile,v
retrieving revision 1.6
diff -c -r1.6 Makefile
*** db/drivers/odbc/Makefile	22 May 2003 14:02:08 -0000	1.6
--- db/drivers/odbc/Makefile	21 Nov 2003 20:46:47 -0000
***************
*** 9,15 ****
  EXTRA_INC = $(ODBCINC)
  DEPENDENCIES = $(GISDEP)
  
! LIBES = $(DBMIDRIVERLIB) $(DBMIBASELIB) $(DBSTUBSLIB) $(GISLIB) $(DATETIMELIB)
OBJS 	=  \
  	connect.o \
--- 9,15 ----
  EXTRA_INC = $(ODBCINC)
  DEPENDENCIES = $(GISDEP)
  
! LIBES = $(DBMIDRIVERLIB) $(DBMIBASELIB) $(DBMIEXTRALIB) $(DBSTUBSLIB) $(GISLIB)
$(DATETIMELIB)
  
  OBJS 	=  \
  	connect.o \
Index: db/drivers/postgres/Makefile
===================================================================
RCS file: /home/grass/grassrepository/grass51/db/drivers/postgres/Makefile,v
retrieving revision 1.11
diff -c -r1.11 Makefile
*** db/drivers/postgres/Makefile	12 Nov 2003 16:23:30 -0000	1.11
--- db/drivers/postgres/Makefile	21 Nov 2003 20:46:47 -0000
***************
*** 11,17 ****
  
  CRYPTLIB = -lcrypt
  
! LIBES = $(DBMIDRIVERLIB) $(DBMIBASELIB) $(SQLPLIB) $(DBSTUBSLIB) \
  	-l$(DBDIALOG_LIBNAME) \
  	$(GISLIB) $(DATETIMELIB) $(PQLIB)
  EXTRA_CFLAGS = $(PQINCPATH) $(TCLINCDIR) $(TKINCDIR)
--- 11,17 ----
  
  CRYPTLIB = -lcrypt
  
! LIBES = $(DBMIDRIVERLIB) $(DBMIBASELIB) $(DBMIEXTRALIB) $(SQLPLIB) $(DBSTUBSLIB)
\
  	-l$(DBDIALOG_LIBNAME) \
  	$(GISLIB) $(DATETIMELIB) $(PQLIB)
  EXTRA_CFLAGS = $(PQINCPATH) $(TCLINCDIR) $(TKINCDIR)

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://www.qsl.net/~km5vy/
 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]
Fri, Nov 21 2003 22:19:08    Mail sent by russo@bogoflux.losalamos.nm.us  
Return-Path <russo@bogoflux.losalamos.nm.us>
Delivered-To grass-bugs@lists.intevation.de
Date Fri, 21 Nov 2003 14:18:35 -0700
From Tom Russo <russo@bogoflux.losalamos.nm.us>
To Tom Russo via RT <grass-bugs@intevation.de>
Subject Re: [bug #2232] (grass) Transaction (russo@bogoflux.losalamos.nm.us)
Message-ID <20031121211835.GD3743@bogoflux.losalamos.nm.us>
References <20031121210755.C308C13B88@lists.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20031121210755.C308C13B88@lists.intevation.de>
User-Agent Mutt/1.4i
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
On Fri, Nov 21, 2003 at 10:07:55PM +0100, a Mr. Richard Feyler of Fort Lee, New
Jersey <grass-bugs@intevation.de> writes 'Dear Rosanne Rosannadanna':
> This one fixes broken stuff in the FreeBSD block of aclocal.m4
> It should have absolutely no effect on any other platform.
> 
> Index: aclocal.m4

Grumble.  Don't apply this yet.  Turns out that I was too hasty in
declaring victory on that one.  There is another pthread-related bomb
very late in the build that my patch didn't fix.  When I built it last
night (and got it to work) I had kludged something additional and this
patch was an attempt to do without that kludge.  I'll not post again
until I absolutely have the patch right and have a final build.

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://www.qsl.net/~km5vy/
 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]
Fri, Nov 21 2003 23:09:43    Mail sent by russo@bogoflux.losalamos.nm.us  
Return-Path <russo@bogoflux.losalamos.nm.us>
Delivered-To grass-bugs@lists.intevation.de
Date Fri, 21 Nov 2003 15:08:42 -0700
From Tom Russo <russo@bogoflux.losalamos.nm.us>
To Tom Russo via RT <grass-bugs@intevation.de>
Subject Re: [bug #2232] (grass) Transaction (russo@bogoflux.losalamos.nm.us)
Message-ID <20031121220842.GE3743@bogoflux.losalamos.nm.us>
References <20031121211908.B45C213B88@lists.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20031121211908.B45C213B88@lists.intevation.de>
User-Agent Mutt/1.4i
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
On Fri, Nov 21, 2003 at 10:19:08PM +0100, a Mr. Richard Feyler of Fort Lee, New
Jersey <grass-bugs@intevation.de> writes 'Dear Rosanne Rosannadanna':
> this bug's URL: http://intevation.de/rt/webrt?serial_num=2232
> 
> Fri, Nov 21 2003 22:19:08: Request 2232 was acted upon.
> 
>  Transaction: Mail sent by russo@bogoflux.losalamos.nm.us
>  
>        Queue: grass
>         Area: grass5.7               
>      Subject: FreeBSD configure/build issues in 5.7
>        Owner: 
>   Requestors: russo@bogoflux.losalamos.nm.us    
>       Status: open
> 
> -------------------------------------------------------------------------
> On Fri, Nov 21, 2003 at 10:07:55PM +0100, a Mr. Richard Feyler of Fort Lee,
New Jersey <grass-bugs@intevation.de> writes 'Dear Rosanne Rosannadanna':
> > This one fixes broken stuff in the FreeBSD block of aclocal.m4
> > It should have absolutely no effect on any other platform.
> > 
> > Index: aclocal.m4
> 
> Grumble.  Don't apply this yet.  Turns out that I was too hasty in
> declaring victory on that one.  There is another pthread-related bomb
> very late in the build that my patch didn't fix.  When I built it last
> night (and got it to work) I had kludged something additional and this
> patch was an attempt to do without that kludge.  I'll not post again
> until I absolutely have the patch right and have a final build.

This needs to be the patch for aclocal.m4 instead of what I had above.
The others stay the same.  This got me all the way through the build
and install process, and I was able to run grass5.7 and view some layers.
It would be great to have them applied to the repository so I can track
the CVS version of 5.7 and build out of the box from now on.

I tried nviz very quickly and got a "cannot find nviz2.2_script" error,
but I see other bugs related to that issue and will figure those out without
posting further to this thread.

diff -c -r1.11 aclocal.m4
*** aclocal.m4  17 Nov 2003 16:00:25 -0000      1.11
--- aclocal.m4  21 Nov 2003 22:03:45 -0000
***************
*** 894,907 ****
        FreeBSD-*)
            # FreeBSD 3.* and greater have ELF.
            SHLIB_CFLAGS="-fPIC"
!           SHLIB_LD="ld -Bshareable -x"
            SHLIB_LD_LIBS='${LIBS}'
            SHLIB_SUFFIX="so"
            DL_OBJS=""
            DL_LIBS=""
-           LDFLAGS="-export-dynamic"
            CC_SEARCH_FLAGS='-Wl,-rpath,${LIB_RUNTIME_DIR}'
            LD_SEARCH_FLAGS='-rpath ${LIB_RUNTIME_DIR}'
            if test "${GRASS_THREADS}" = "1" ; then
                # The -pthread needs to go in the CFLAGS, not LIBS
                LIBS=`echo $LIBS | sed s/-pthread//`
--- 894,911 ----
        FreeBSD-*)
            # FreeBSD 3.* and greater have ELF.
            SHLIB_CFLAGS="-fPIC"
!           SHLIB_LD="-shared"
            SHLIB_LD_LIBS='${LIBS}'
            SHLIB_SUFFIX="so"
            DL_OBJS=""
            DL_LIBS=""
            CC_SEARCH_FLAGS='-Wl,-rpath,${LIB_RUNTIME_DIR}'
            LD_SEARCH_FLAGS='-rpath ${LIB_RUNTIME_DIR}'
+               # this is where most installed packages go
+           CPPFLAGS="$CPPFLAGS -I/usr/local/include"
+           LDFLAGS="$LDFLAGS -pthread -L/usr/local/lib"
+               # require this for GL probe to work
+           CFLAGS="$CFLAGS -pthread"
            if test "${GRASS_THREADS}" = "1" ; then
                # The -pthread needs to go in the CFLAGS, not LIBS
                LIBS=`echo $LIBS | sed s/-pthread//`

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://www.qsl.net/~km5vy/
 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]
Mon, Jan 12 2004 18:44:29    Mail sent by guest  
Tom,

thanks for the patches. I have merged them into CVS.
Please upgrade from CVS and check, if GRASS 5.7 compiles now.

Kind regards

 Markus Neteler
Sat, Jan 24 2004 22:24:49    Mail sent by russo@bogoflux.losalamos.nm.us  
Return-Path <russo@bogoflux.losalamos.nm.us>
Delivered-To grass-bugs@lists.intevation.de
Date Sat, 24 Jan 2004 14:24:05 -0700
From Tom Russo <russo@bogoflux.losalamos.nm.us>
To guest user via RT <grass-bugs@intevation.de>
Subject Re: [bug #2232] (grass) Transaction (guest)
Message-ID <20040124212405.GA32151@bogoflux.losalamos.nm.us>
References <20040112174429.31DEE13BC1@lists.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20040112174429.31DEE13BC1@lists.intevation.de>
User-Agent Mutt/1.4.1i
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Yes, the applied patch does indeed fix the build problems I had.  I removed
my own modified files, did a cvs update and tried to build, and the problems
I'd seen before were gone.

However, something was committed to the repository in vector/v.kernel/main.c
that does not compile cleanly under the version of GCC distributed with FreeBSD
(GCC 2.95) (there's a function definition nested inside of a function, and GCC
2.95 doesn't like it).  To get rid of that error I had to install gcc 3.2 from
the ports collection and tell configure to use that.

So in summary for completeness' sake, as it stands right now there are no 
showstoppers in the Grass 5.7 build process IF I use the following configure
line:

CC=gcc32 CXX=g++32 CPPFLAGS="-I/usr/local/include/freetype2" LIBS="-L/usr/X11R6/lib"
LDFLAGS="-L/usr/X11R6/lib" ./configure --with-grass50=/users/russo/src/grass_experimental/grass53_ex
p_2003_11_15/
--with-tcltk-includes="/usr/local/include/tcl8.3 /usr/local/include/tk8.3" --with-tcltk-libs="/usr/l
ocal/lib/tcl8.3
/usr/local/lib/tk8.3" --with-opengl-includes=/usr/X11R6/include --with-opengl-libs=/usr/X11R6/lib
--with-freetype=yes --prefix=/users/russo

then make sure that GNU make is in my path as "make" prior to the non-gnu
make that comes with freebsd:

  cd ~/src/grass_experimental/grass57_exp_2003_11_15
  mkdir bin
  ln -s /usr/local/bin/gmake bin/make
  setenv PATH ~/src/grass_experimental/grass57_exp_2003_11_15/bin:$PATH

This step is necessary because the makefiles assume that "make" gets you 
GNU make, which is not true on FreeBSD.  

THEN make using the following line:

LIB_RUNTIME_DIR=/users/russo/src/grass_experimental/grass57_exp_2003_11_15/dist.i386-unknown-freebsd
4.9/lib
make

With the patches you committed, and this set of build steps, Grass 5.7 builds
and runs just fine under FreeBSD

Thank you.


Wed, Mar 24 2004 11:53:22    Mail sent by mneteler  
The nested function in v.kernel has been resolved.

So we can close the report.

M Neteler
Wed, Mar 24 2004 11:53:26    Status changed to resolved by mneteler  
Comment | Reply | Take | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request