FWIW, it's now possible to build GRASS on Linux with most of the main
libraries as shared libraries. Brief instructions are in mk/README.
--
Glynn Clements <glynn.clements@virgin.net>
Hi Glynn,
I found out that I was missing a couple of odbc files and I installed
them and the problem was solved.
Thanks
Venkat
Hi,
compliments to Glynn - I was able to compile GRASS
with shared libraries and reduce the binaries size to
31MB (was around 100MB before, if I recall correctly).
Find attached makeshared.sh (must be locally customized),
which is based on Glynn's instructions.
Thanks, Glynn! This is a real step forward.
Markus
(attachments)
makeshared.sh (587 Bytes)
On Tue, Apr 16, 2002 at 02:32:22PM +0100, Glynn Clements wrote:
FWIW, it's now possible to build GRASS on Linux with most of the main
libraries as shared libraries. Brief instructions are in mk/README.
Glynn,
just curious: Is there a way to allow for individual compiles with
make? E.g.
src/libes/proj > make
makefile:2: head.mk: File or directory not found
makefile:60: tail.mk: File or directory not found
make: *** No rule to make target 'tail.mk'. Stop.
Perhaps the full path could be written from
mk/mkmakefiles
?
Before breaking anything, I would like to ask.
Markus
Markus Neteler wrote:
> FWIW, it's now possible to build GRASS on Linux with most of the main
> libraries as shared libraries. Brief instructions are in mk/README.Glynn,
just curious: Is there a way to allow for individual compiles with
make? E.g.src/libes/proj > make
makefile:2: head.mk: File or directory not found
makefile:60: tail.mk: File or directory not found
make: *** No rule to make target 'tail.mk'. Stop.
See the "gmake5" script which is created during the build process (or
by "make gmake".
Perhaps the full path could be written from
mk/mkmakefiles
?Before breaking anything, I would like to ask.
The problem is that the makefiles need vars.mk (which is basically the
"head" file), which lives in the build directory. But the makefiles
generated by "make makefiles" or "mk/mkmakefiles" aren't specific to a
particular configuration, so they can't reference the build directory.
--
Glynn Clements <glynn.clements@virgin.net>
On Sun, Apr 21, 2002 at 10:41:27AM +0100, Glynn Clements wrote:
Markus Neteler wrote:
> > FWIW, it's now possible to build GRASS on Linux with most of the main
> > libraries as shared libraries. Brief instructions are in mk/README.
>
> Glynn,
>
> just curious: Is there a way to allow for individual compiles with
> make? E.g.
>
> src/libes/proj > make
> makefile:2: head.mk: File or directory not found
> makefile:60: tail.mk: File or directory not found
> make: *** No rule to make target 'tail.mk'. Stop.See the "gmake5" script which is created during the build process (or
by "make gmake".
Yes - but then I receive again a static library, right?
> Perhaps the full path could be written from
> mk/mkmakefiles
> ?
>
> Before breaking anything, I would like to ask.The problem is that the makefiles need vars.mk (which is basically the
"head" file), which lives in the build directory. But the makefiles
generated by "make makefiles" or "mk/mkmakefiles" aren't specific to a
particular configuration, so they can't reference the build directory.
Ah, ok. So I'll recompile from the top directory.
No problem,
Markus
Markus Neteler wrote:
> > > FWIW, it's now possible to build GRASS on Linux with most of the main
> > > libraries as shared libraries. Brief instructions are in mk/README.
> >
> > Glynn,
> >
> > just curious: Is there a way to allow for individual compiles with
> > make? E.g.
> >
> > src/libes/proj > make
> > makefile:2: head.mk: File or directory not found
> > makefile:60: tail.mk: File or directory not found
> > make: *** No rule to make target 'tail.mk'. Stop.
>
> See the "gmake5" script which is created during the build process (or
> by "make gmake".Yes - but then I receive again a static library, right?
No. The alternate build mechanism (from the "mk" directory) creates
its own "gmake5" script, which basically just runs "make" with the
right options.
Static vs shared depends upon the mid.mk file. If you use the default
file, you get static libraries; if you replace it with mid.mk.shlib,
you get shared libraries.
--
Glynn Clements <glynn.clements@virgin.net>
On Sun, Apr 21, 2002 at 03:59:22PM +0100, Glynn Clements wrote:
Markus Neteler wrote:
> > > > FWIW, it's now possible to build GRASS on Linux with most of the main
> > > > libraries as shared libraries. Brief instructions are in mk/README.
> > >
> > > Glynn,
> > >
> > > just curious: Is there a way to allow for individual compiles with
> > > make? E.g.
> > >
> > > src/libes/proj > make
> > > makefile:2: head.mk: File or directory not found
> > > makefile:60: tail.mk: File or directory not found
> > > make: *** No rule to make target 'tail.mk'. Stop.
> >
> > See the "gmake5" script which is created during the build process (or
> > by "make gmake".
>
> Yes - but then I receive again a static library, right?No. The alternate build mechanism (from the "mk" directory) creates
its own "gmake5" script, which basically just runs "make" with the
right options.Static vs shared depends upon the mid.mk file. If you use the default
file, you get static libraries; if you replace it with mid.mk.shlib,
you get shared libraries.
Sorry - I didn't realize that "gmake5" was generated in the top
directory (usually it was bin.$ARCH). Of course I get shared libs
with that version of "gmake5".
Markus
On Sat, Apr 20, 2002 at 08:43:57AM +0200, Markus Neteler wrote:
compliments to Glynn - I was able to compile GRASS
with shared libraries and reduce the binaries size to
31MB (was around 100MB before, if I recall correctly).
A useful addition.
We could ship it with 5.0.0, but we should not make it the default,
as this usually is a part that will create difficulties on several platforms.
Glynn: Are you using something platform portable like libtool already?
Bernhard Reiter wrote:
> compliments to Glynn - I was able to compile GRASS
> with shared libraries and reduce the binaries size to
> 31MB (was around 100MB before, if I recall correctly).A useful addition.
We could ship it with 5.0.0, but we should not make it the default,
as this usually is a part that will create difficulties on several platforms.Glynn: Are you using something platform portable like libtool already?
No, and I don't intend to; actually, if GRASS ever starts using
libtool, I'm off.
At present, the situation is complicated by the fact that the
Gmakefiles have to work with two separate build systems: the original
"gmake" system, plus the GNU make based stuff in "mk". You have to use
the latter if you want shared libraries (or if you want to build
outside of the source tree).
My approach would be to have a selection of "lib.mk" files. The
configure script would select one of them, according to the target
platform, to be included from each makefile.
If there isn't a lib.mk file for a particular platform (either because
the platform doesn't support shared libraries, or because no-one has
written the lib.mk file yet), it would fall back to producing static
libraries.
The current mechanism for building shared libraries is just a
substitute mid.mk file with different settings for the make variables
which control linking.
Also, while this might be useful for binary distributions (I'm not
sure whether the advantages outweight the potential problems), I did
it primarily for the benefit of developers.
First, if you're modifying library code, you only need to rebuild the
library; you don't have to re-link the programs. Second, the
information obtained from running "nm" or "ldd" on an executable is
more useful when the executable is linked against shared versions of
the GRASS libraries.
--
Glynn Clements <glynn.clements@virgin.net>
On Sun, Apr 21, 2002 at 10:08:11PM +0100, Glynn Clements wrote:
Bernhard Reiter wrote:
> Glynn: Are you using something platform portable like libtool already?
No, and I don't intend to; actually, if GRASS ever starts using
libtool, I'm off.
Any reasons for this?
Bernhard Reiter wrote:
> > Glynn: Are you using something platform portable like libtool already?
>
> No, and I don't intend to; actually, if GRASS ever starts using
> libtool, I'm off.Any reasons for this?
Primarily the fact that it makes the build process totally
incomprehensible to anyone other than the libtool authors.
With a normal build procedure, the user runs "make", which reads the
makefile, and runs the compiler or linker in a manner which follows
logically from the contents of the makefile.
With libtool, make runs libtool; libtool is FOUR THOUSAND lines of
Bourne-shell script (not the most legible of languages) which,
somewhere in its depths, runs the compiler or linker; usually with
some additional switches (which you never asked for), set somewhere
within the libtool script (good luck trying to find out where,
though).
A secondary reason is that libtool forcibly adds "-rpath" to the
linker switches, which means that the executables have the full path
to the shared libraries hardcoded within them. You cannot move the
shared libraries afterwards (-rpath overrides both ld.so.conf and
$LD_LIBRARY_PATH).
If you want to disable the use of -rpath at build time, it's easier to
modify (or wrap) the linker to ignore it than it is to figure out how
to stop libtool from doing it. If you don't discover the problem until
later, you have to modify the loader (e.g. ld-linux.so) to ignore the
embedded rpath.
--
Glynn Clements <glynn.clements@virgin.net>