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