this bug's URL: http://intevation.de/rt/webrt?serial_num=5028
-------------------------------------------------------------------------
Subject: simwe needs indirectly linked vector libs
Platform: Mac OSX
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: 6.1+
Some of the libraries needed by the simwe/simlib themselves use the vector libraries, but the vector
libraries are not directly linked into simlib. This causes a build failure in many cases because the
linker can't find those indirectly linked libraries (at least with the Mac OS X linker).
When it's a first-time build or a version upgrade, there is no GRASS installed. Or in a SDK build (ie
on Mac OS X), the SDK overrides the usual system paths, and GRASS does not exist in the SDK.
Another possible problem is if the vector libs get new functions, a previously installed GRASS' vector
libs will be used and not have those functions.
A quick fix is to install GRASS after simwe build failed, so at least the libraries are available, then
rebuild simwe. But this is not good - it doesn't work for the SDK case, and it's possible the build will
go directly into a distribution install, and not a normal install at all.
To fix, edit simwe/simlib/makefile: add $(VECTLIB) to EXTRA_LIBS, and add $(VECTDEP) to
DEPENDENCIES. At least that's what I do for now.
-------------------------------------------- Managed by Request Tracker
Request Tracker wrote:
this bug's URL: http://intevation.de/rt/webrt?serial_num=5028
-------------------------------------------------------------------------
Subject: simwe needs indirectly linked vector libs
Platform: Mac OSX
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: 6.1+
Some of the libraries needed by the simwe/simlib themselves use the vector libraries, but the vector
libraries are not directly linked into simlib. This causes a build failure in many cases because the
linker can't find those indirectly linked libraries (at least with the Mac OS X linker).
When it's a first-time build or a version upgrade, there is no GRASS installed. Or in a SDK build (ie
on Mac OS X), the SDK overrides the usual system paths, and GRASS does not exist in the SDK.
Another possible problem is if the vector libs get new functions, a previously installed GRASS' vector
libs will be used and not have those functions.
A quick fix is to install GRASS after simwe build failed, so at least the libraries are available, then
rebuild simwe. But this is not good - it doesn't work for the SDK case, and it's possible the build will
go directly into a distribution install, and not a normal install at all.
To fix, edit simwe/simlib/makefile: add $(VECTLIB) to EXTRA_LIBS, and add $(VECTDEP) to
DEPENDENCIES. At least that's what I do for now.
Ideally, this should be fixed by adding any required libraries to the
library variable in Grass.make.in.
The individual Makefiles should only need to specify libraries which
the module uses directly (i.e. where the module's source code contains
a call to a function in that library). The build system should take
care of the rest.
For shared GRASS libraries, the dependencies shouldn't be necessary.
If the linker only finds them when there is an existing installation,
that implies that the link flags need something similar to the
-Wl,-rpath-link,${LIB_RUNTIME_DIR} switch which is used on Linux.
Static libraries don't have dependency information, so it needs to be
specified explicitly in Grass.make.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote on 08/21/2006 06:19 AM:
Request Tracker wrote:
this bug's URL: http://intevation.de/rt/webrt?serial_num=5028
-------------------------------------------------------------------------
Subject: simwe needs indirectly linked vector libs
Platform: Mac OSX
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: 6.1+
Some of the libraries needed by the simwe/simlib themselves use the vector libraries, but the vector
libraries are not directly linked into simlib. This causes a build failure in many cases because the
linker can't find those indirectly linked libraries (at least with the Mac OS X linker).
When it's a first-time build or a version upgrade, there is no GRASS installed. Or in a SDK build (ie
on Mac OS X), the SDK overrides the usual system paths, and GRASS does not exist in the SDK.
Another possible problem is if the vector libs get new functions, a previously installed GRASS' vector
libs will be used and not have those functions.
A quick fix is to install GRASS after simwe build failed, so at least the libraries are available, then
rebuild simwe. But this is not good - it doesn't work for the SDK case, and it's possible the build will
go directly into a distribution install, and not a normal install at all.
To fix, edit simwe/simlib/makefile: add $(VECTLIB) to EXTRA_LIBS, and add $(VECTDEP) to
DEPENDENCIES. At least that's what I do for now.
Ideally, this should be fixed by adding any required libraries to the
library variable in Grass.make.in.
The individual Makefiles should only need to specify libraries which
the module uses directly (i.e. where the module's source code contains
a call to a function in that library). The build system should take
care of the rest.
For shared GRASS libraries, the dependencies shouldn't be necessary.
If the linker only finds them when there is an existing installation,
that implies that the link flags need something similar to the
-Wl,-rpath-link,${LIB_RUNTIME_DIR} switch which is used on Linux.
Static libraries don't have dependency information, so it needs to be
specified explicitly in Grass.make.
I have made the changes for both LIDAR and SIMWE, I hope I got it right.
Markus
Markus Neteler wrote:
>> this bug's URL: http://intevation.de/rt/webrt?serial_num=5028
>> -------------------------------------------------------------------------
>>
>> Subject: simwe needs indirectly linked vector libs
>> To fix, edit simwe/simlib/makefile: add $(VECTLIB) to EXTRA_LIBS, and add $(VECTDEP) to
>> DEPENDENCIES. At least that's what I do for now.
>
> Ideally, this should be fixed by adding any required libraries to the
> library variable in Grass.make.in.
>
> The individual Makefiles should only need to specify libraries which
> the module uses directly (i.e. where the module's source code contains
> a call to a function in that library). The build system should take
> care of the rest.
>
> For shared GRASS libraries, the dependencies shouldn't be necessary.
> If the linker only finds them when there is an existing installation,
> that implies that the link flags need something similar to the
> -Wl,-rpath-link,${LIB_RUNTIME_DIR} switch which is used on Linux.
>
> Static libraries don't have dependency information, so it needs to be
> specified explicitly in Grass.make.
I have made the changes for both LIDAR and SIMWE, I hope I got it right.
I've just committed changes to add the dependency information, as well
as add the LIDAR, SIMWE and LRS libraries to the build system (I had
to resolve a couple of conflicts due to your concurrent LIDAR/SIMWE
changes).
The setting for LIB_NAME was missing from the library Makefiles for
LIDAR/SIMWE, so I've added that.
Primarily, I added the dependency information for all of the GRASS
libraries, based upon the database created by tools/sql.sh. This only
covers dependencies between GRASS libraries; any external dependencies
will need to be added separately.
--
Glynn Clements <glynn@gclements.plus.com>