Details Ticket 2544


Comment | Reply | Take | Open


Serial Number 2544
Subject grass libs built with paths to source tree, not install dir
Area grass6
Queue grass
Requestors kyngchaos@charter.net
Owner none
Status resolved
Last User Contact Wed Aug 31 21:48:35 2005 (3 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Wed Aug 31 21:48:38 2005 (3 yr ago)
Created Sun Jul 18 20:00:52 2004 (4 yr ago)

Transaction History Ticket 2544


Sun, Jul 18 2004 20:00:52    Request created by guest  
Subject: grass libs built with paths to source tree, not install dir

Platform: other
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: CVS 2004-7-17

(This is the way it seems to work on OS X at least. It may affect other platforms
as well.)

GRASS 5.7 libraries are built with embedded paths pointing to the source tree.
Everything that is 
linked to these libs points to the source tree instead of the installed libs.
(Not sure if it's an Apple 
thing, but linking to them uses the embedded path/libname instead of where they
physically are.)  
This becomes a problem if GDAL is patched to use GRASS 5.7 libs instead of libgrass.
Normally this isn't a big deal - if the source is removed after installation,
dyld is smart enough to try 
defined library paths if it can't find libraries in the original location.  But,
say the source is built 
inside one's home Documents folder (a reasonable location).  On Mac OS X, a users'
home folder has 
read access for everyone, but the Documents subfolder does not.  GRASS runs as
the user's ID and 
doesn't have a problem, but MapServer runs as the webserver.  Before dyld has
a chance to not find 
the source libs so it can try elsewhere, it fails because it can't get past the
Documents folder.


I found some commented lines in configure to use as a starting point to add a
few needed darwin 
options to fix this - darwin needs -install_name (at least), and -compatibility_version
and 
-current_version (may be optional, don't know).  I ended up with:

SHLIB_LD="cc -dynamiclib -Wl,-flat_namespace,-U,_cuserid -undefined suppress
-compatibility_version 5.7 -current_version 5.7 -install_name \${LIB_RUNTIME_DIR}/
lib\${LIB_NAME}\${SHLIB_SUFFIX} \${LDFLAGS}"

It seems GRASS_SHLIB_LD_EXTRAS isn't used, so I had to put it all in SHLIB_LD.
This builds the libs 
with the correct embedded paths (and the patched GDAL, after rebuilding, is happy).
It works, but I 
don't know enough to say that this is the right way to do it.  I hard-coded the
version numbers 
because with the CVS version, the command that creates the LIB_VER var ends up
with '5.7.', and the 
version options don't like that trailing '.' (and I don't know enough about sed
to fix LIB_VER).

A side note on the linking options - undefined-suppress disables prebind, so
prebind could be 
removed from LDFLAGS.  Harmless warnings otherwise, no big deal.
Sun, Jul 18 2004 23:37:56    Mail sent by paul-grass@stjohnspoint.co.uk  
Return-Path <paul-grass@stjohnspoint.co.uk>
Delivered-To grass-bugs@lists.intevation.de
Date Sun, 18 Jul 2004 22:37:50 +0100 (BST)
From Paul Kelly <paul-grass@stjohnspoint.co.uk>
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #2544] (grass) grass libs built with paths to source tree, not install dir
In-Reply-To <20040718180052.84350139C8@lists.intevation.de>
Message-ID <Pine.LNX.4.60.0407182231290.5181@agrippa.ukshells.co.uk>
References <20040718180052.84350139C8@lists.intevation.de>
MIME-Version 1.0
Content-Type MULTIPART/MIXED; BOUNDARY="182016655-1384609609-1090186670=:5181"
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--182016655-1384609609-1090186670=:5181
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Sun, 18 Jul 2004, Request Tracker wrote:

> this bug's URL: http://intevation.de/rt/webrt?serial_num=2544
> -------------------------------------------------------------------------
>
> Subject: grass libs built with paths to source tree, not install dir
>
> Platform: other
> grass obtained from: Trento Italy site
> grass binary for platform: Compiled from Sources
> GRASS Version: CVS 2004-7-17
>
> (This is the way it seems to work on OS X at least. It may affect other platforms
as well.)
>
> GRASS 5.7 libraries are built with embedded paths pointing to the source tree.
Everything that is
> linked to these libs points to the source tree instead of the installed libs.
(Not sure if it's an Apple
> thing, but linking to them uses the embedded path/libname instead of where
they physically are.)
> This becomes a problem if GDAL is patched to use GRASS 5.7 libs instead of
libgrass.

Please see the attached patch as a possible solution (includes some 
changes to include/Make/Shlib.make that should hae been made at the same 
time as the changhes to SC_CONFIG_CFLAGS last week.

The only reason I haven't applied it to CVS yet is that I remember some 
discussion on the mailing list a while ago about the -rpath linker option 
and whether it was a good or a bad idea (can't remember which). I don't 
want to make things worse but it probably should be applied as soon as 
possible (unfortunately I don't have any more time tonight).

>
> Normally this isn't a big deal - if the source is removed after installation,
dyld is smart enough to try
> defined library paths if it can't find libraries in the original location.
But, say the source is built
> inside one's home Documents folder (a reasonable location).  On Mac OS X, a
users' home folder has
> read access for everyone, but the Documents subfolder does not.  GRASS runs
as the user's ID and
> doesn't have a problem, but MapServer runs as the webserver.  Before dyld has
a chance to not find
> the source libs so it can try elsewhere, it fails because it can't get past
the Documents folder.
>
>
> I found some commented lines in configure to use as a starting point to add
a few needed darwin
> options to fix this - darwin needs -install_name (at least), and -compatibility_version
and
> -current_version (may be optional, don't know).  I ended up with:
>
> SHLIB_LD="cc -dynamiclib -Wl,-flat_namespace,-U,_cuserid -undefined suppress
> -compatibility_version 5.7 -current_version 5.7 -install_name \${LIB_RUNTIME_DIR}/
> lib\${LIB_NAME}\${SHLIB_SUFFIX} \${LDFLAGS}"
>
> It seems GRASS_SHLIB_LD_EXTRAS isn't used, so I had to put it all in SHLIB_LD.
This builds the libs
> with the correct embedded paths (and the patched GDAL, after rebuilding, is
happy).  It works, but I
> don't know enough to say that this is the right way to do it.  I hard-coded
the version numbers
> because with the CVS version, the command that creates the LIB_VER var ends
up with '5.7.', and the
> version options don't like that trailing '.' (and I don't know enough about
sed to fix LIB_VER).

GRASS_SHLIB_LD_EXTRAS should be used now if the attach patch is applied. 
About the LIB_VAR variable: the sed construction worked for 5.3 where the 
version number was of the form 5.3-cvs. For 5.7 it is 5.7.-cvs or 5.7.cvs. 
I don't know if there's a good reason for this or not--perhaps it could be 
changed back to the 5.3 version numbering system to make things simpler.

>
> A side note on the linking options - undefined-suppress disables prebind, so
prebind could be
> removed from LDFLAGS.  Harmless warnings otherwise, no big deal.

I think -undefined_suppress can probably be removed now as all the 
relevant library Makefiles contain the proper EXTRA_LIBS line.

Paul

--182016655-1384609609-1090186670=:5181
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="shlib.diff"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.60.0407182237500.5181@agrippa.ukshells.co.uk>
Content-Description: 
Content-Disposition: attachment; filename="shlib.diff"

PyBHcmFzcy5tYWtlDQo/IFBsYXRmb3JtLm1ha2UNCj8gc2hsaWIuZGlmZg0K
SW5kZXg6IFNobGliLm1ha2UNCj09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJD
UyBmaWxlOiAvZ3Jhc3NyZXBvc2l0b3J5L2dyYXNzNTEvaW5jbHVkZS9NYWtl
L1NobGliLm1ha2Usdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjkNCmRpZmYg
LXUgLXIxLjkgU2hsaWIubWFrZQ0KLS0tIFNobGliLm1ha2UJMTMgSnVsIDIw
MDQgMTE6Mzk6MzAgLTAwMDAJMS45DQorKysgU2hsaWIubWFrZQkxOCBKdWwg
MjAwNCAyMTowODoyMyAtMDAwMA0KQEAgLTksNyArOSw4IEBADQogTkxTX0NG
TEFHUz0kKEdFVEhPU1ROQU1FKSAkKFpMSUJJTkNQQVRIKSAkKFBJQ0ZMQUdT
KSAkKERFRlMpDQogDQogQ0ZMQUdTICs9ICQoU0hMSUJfQ0ZMQUdTKSAkKE5M
U19DRkxBR1MpDQotTERGTEFHUyArPSAkKFNITElCX0xERkxBR1MpDQorTElC
X1JVTlRJTUVfRElSID0gJChBUkNIX0xJQkRJUikNCitMREZMQUdTICs9ICQo
R1JBU1NfU0hMSUJfTERfRVhUUkFTKSAkKExEX1NFQVJDSF9GTEFHUykNCiAN
CiAkKFNITElCKTogJChTSExJQl9PQkpTKQ0KIAkkKFNITElCX0xEKSAtbyAk
QCAkKExERkxBR1MpICReICQoRVhUUkFfTElCUykNCg==

--182016655-1384609609-1090186670=:5181--


Mon, Jul 19 2004 00:10:44    Mail sent by glynn.clements@virgin.net  
Return-Path <glynn.clements@virgin.net>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <16634.62725.795358.83767@cerise.nosuchdomain.co.uk>
Date Sun, 18 Jul 2004 23:09:09 +0100
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
From Glynn Clements <glynn.clements@virgin.net>
To Paul Kelly <paul-grass@stjohnspoint.co.uk>
Cc Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #2544] (grass) grass libs built with paths to source tree, not install dir
In-Reply-To <Pine.LNX.4.60.0407182231290.5181@agrippa.ukshells.co.uk>
References <20040718180052.84350139C8@lists.intevation.de> <Pine.LNX.4.60.0407182231290.5181@agrippa.ukshells.co.uk>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Paul Kelly wrote:

> Please see the attached patch as a possible solution (includes some 
> changes to include/Make/Shlib.make that should hae been made at the same 
> time as the changhes to SC_CONFIG_CFLAGS last week.
> 
> The only reason I haven't applied it to CVS yet is that I remember some 
> discussion on the mailing list a while ago about the -rpath linker option 
> and whether it was a good or a bad idea (can't remember which).

On Linux, it's bad. It embeds the library search path into the binary,
and that path takes precedence over $LD_LIBRARY_PATH and ld.so.conf,
so you can't force the use of a different library directory at run
time (other than by deleting the libraries from the -rpath directory).

It is sometimes used as a brute-force "fix" by developers who have
become fed up with users who don't know how to make ld-linux.so look
in the right place for the libraries. IOW, eliminate any potential for
configuration problems by eliminating any potential for configuration.

-- 
Glynn Clements <glynn.clements@virgin.net>


Mon, Jul 19 2004 16:22:51    Mail sent by kyngchaos@charter.net  
Return-Path <kyngchaos@charter.net>
Delivered-To grass-bugs@lists.intevation.de
X-Ironport-AV i="3.81R,178,1083556800"; d="scan'208"; a="107646177:sNHT13747764"
Mime-Version 1.0 (Apple Message framework v618)
In-Reply-To <20040718221045.2034F139C8@lists.intevation.de>
References <20040718221045.2034F139C8@lists.intevation.de>
Content-Type text/plain; charset=US-ASCII; format=flowed
Message-Id <158F2F7A-D98F-11D8-96E5-000A95DB713E@charter.net>
Content-Transfer-Encoding 7bit
From William Kyngesburye <kyngchaos@charter.net>
Subject Re: [bug #2544] (grass) Transaction (glynn.clements@virgin.net)
Date Mon, 19 Jul 2004 09:22:37 -0500
To Glynn Clements via RT <grass-bugs@intevation.de>
X-Mailer Apple Mail (2.618)
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
This patch seems harmless for Linux - it only enables 
GRASS_SHLIB_LD_EXTRAS to be inserted into the linking.  And the only 
thing in configure I found that set it is Darwin (tho it's commented 
out right now).  I had to tweak the install_name option, and I don't 
understand the seg1addr option (so I left it out).

As for embedding the path - it seems this is yet another problem with 
Apple's linker, no option needed and it automatically embeds the path, 
which looks like it defaults to where it was built.

I guess the prebind option is harmless to leave in if undefined 
suppress is removed.  But there's no ported stuff (that I've found) 
that GRASS uses that's built prebound (including even the 
Apple-supplied X11 libraries and other /usr/lib stuff), so it gets 
disabled anyways.


So, here is what I came up with:

Your shlib.make patch, but remove the LIB_RUNTIME_DIR - it's already 
set correctly in platform.make.  Changing it back to the source tree 
here breaks the whole point of embedding the install path (at least for 
Mac OS X).  So the only change is:

LDFLAGS += $(GRASS_SHLIB_LD_EXTRAS) $(LD_SEARCH_FLAGS)

Add to platform.make.in:

GRASS_SHLIB_LD_EXTRAS = @GRASS_SHLIB_LD_EXTRAS@

In the Rhapsody-*|Darwin-*) section of configure:

GRASS_SHLIB_LD_EXTRAS="-compatibility_version 5.7 -current_version 5.7 
-install_name \${LIB_RUNTIME_DIR}/lib\${LIB_NAME}\${SHLIB_SUFFIX} 
-prebind"
SHLIB_LD="cc -dynamiclib -Wl,-flat_namespace,-U,_cuserid"
LDFLAGS=""


Another problem now (it didn't happen initially when I used my quick 
hack to SHLIB_LD).  In diglib, GRASS_SHLIB_LD_EXTRAS gets inserted into 
the first gcc line (for port_test.c).  I think some others get it too, 
but this is the first one I saw.


On Jul 18, 2004, at 5:10 PM, Glynn Clements via RT wrote:

> Paul Kelly wrote:
>
>> Please see the attached patch as a possible solution (includes some
>> changes to include/Make/Shlib.make that should hae been made at the 
>> same
>> time as the changhes to SC_CONFIG_CFLAGS last week.
>>
>> The only reason I haven't applied it to CVS yet is that I remember 
>> some
>> discussion on the mailing list a while ago about the -rpath linker 
>> option
>> and whether it was a good or a bad idea (can't remember which).
>
> On Linux, it's bad. It embeds the library search path into the binary,
> and that path takes precedence over $LD_LIBRARY_PATH and ld.so.conf,
> so you can't force the use of a different library directory at run
> time (other than by deleting the libraries from the -rpath directory).
>
> It is sometimes used as a brute-force "fix" by developers who have
> become fed up with users who don't know how to make ld-linux.so look
> in the right place for the libraries. IOW, eliminate any potential for
> configuration problems by eliminating any potential for configuration.
>
> -- 
> Glynn Clements <glynn.clements@virgin.net>
>
>
-----
William Kyngesburye <kyngchaos@charter.net>
http://webpages.charter.net/kyngchaos/

"Oh, look, I seem to have fallen down a deep, dark hole.  Now what does 
that remind me of?  Ah, yes - life."

- Marvin


Sat, Jul 24 2004 23:42:07    Mail sent by kyngchaos@charter.net  
Return-Path <kyngchaos@charter.net>
Delivered-To grass-bugs@lists.intevation.de
X-Ironport-AV i="3.83,86,1089000000"; d="scan'208"; a="134190690:sNHT13185208"
Mime-Version 1.0 (Apple Message framework v618)
In-Reply-To <20040718213756.D7E53139FE@lists.intevation.de>
References <20040718213756.D7E53139FE@lists.intevation.de>
Content-Type text/plain; charset=US-ASCII; format=flowed
Message-Id <47FB26ED-DDBA-11D8-8616-000A95DB713E@charter.net>
Content-Transfer-Encoding 7bit
From William Kyngesburye <kyngchaos@charter.net>
Subject Re: [bug #2544] (grass) grass libs built with paths to
Date Sat, 24 Jul 2004 16:41:54 -0500
To Paul Kelly via RT <grass-bugs@intevation.de>
X-Mailer Apple Mail (2.618)
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
I've had a chance to work on this again.  I'm dividing this problem up 
into two levels: getting the shared lib paths right, and making it so 
it works with the patched GDAL.

I had problems getting it to work right with your patch to Shlib.make, 
so I stayed with my original method of adding to SHLIB_LD.

1. To get the lib paths set, I added "-compatibility_version 5.7 
-current_version 5.7 -install_name 
\${LIB_RUNTIME_DIR}/lib\${LIB_NAME}\${SHLIB_SUFFIX}" to SHLIB_LD in 
configure (for the Darwin system).

Like you said, undefined suppress isn't needed any more, and I also 
removed \${LDFLAGS} from SHLIB_LD, since it seems to be added elsewhere 
anyways.  And, since prebind gets disabled for various reasons, might 
as well remove that too.

2. Getting GRASS to build with the patched GDAL (to use GRASS 5.7 libs 
instead of libgrass) was a bit of a chore.

 From scratch, with neither gdal nor grass installed, no additional 
changes are needed.  Just build gdal without grass (it's not there 
yet), build grass with gdal, then rebuild gdal with grass.

But, once they're built against each other, I have problems building a 
new grass.  I get multiple defs errors in libgrass_gproj.  One way to 
get it to work is to temporarily install gdal without grass, build 
grass, then reinstall gdal+grass.  Yuck.

Another way requires Mac OS 10.3, it won't work on 10.2 or 10.1.  That 
is, build with two-level namespace.

First I set the MACOSX_DEPLOYMENT_TARGET env var to 10.3 (default is 
10.1).  Right now I do this externally on the command line, but maybe 
there's a way to add it to configure?  Or at least add a test to see 
what MACOSX_DEPLOYMENT_TARGET set to and set SHLIB_LD appropriately.

Then for SHLIB_LD, get rid of the whole -Wl options and replace it with 
"-undefined dynamic_lookup".  That dynamic_lookup is why 10.3 is 
needed.  And I need that because _cuserid is undefined somewhere in the 
DB stuff.  If you know how to fix _cuserid, dynamic_lookup wouldn't be 
needed and it wouldn't be restricted to 10.3.

whew!

summary of SHLIB_LD in configure:

- minimal, Mac OS 10.2 or 10.1

SHLIB_LD="cc -dynamiclib -Wl,-flat_namespace,-U,_cuserid 
-compatibility_version 5.7 -current_version 5.7 -install_name 
\${LIB_RUNTIME_DIR}/lib\${LIB_NAME}\${SHLIB_SUFFIX}"

- Mac OS 10.3

SHLIB_LD="cc -dynamiclib -undefined dynamic_lookup 
-compatibility_version 5.7 -current_version 5.7 -install_name 
\${LIB_RUNTIME_DIR}/lib\${LIB_NAME}\${SHLIB_SUFFIX}"

-----
William Kyngesburye <kyngchaos@charter.net>
http://webpages.charter.net/kyngchaos/

"I ache, therefore I am.  Or in my case - I am, therefore I ache."

- Marvin


Sat, Dec 18 2004 19:45:37    Mail sent by woklist@charter.net  
Return-Path <woklist@charter.net>
Delivered-To grass-bugs@lists.intevation.de
X-Ironport-AV i="3.88,74,1102309200"; d="scan'208"; a="591842723:sNHT24335876"
In-Reply-To <16634.62725.795358.83767@cerise.nosuchdomain.co.uk>
References <20040718180052.84350139C8@lists.intevation.de> <Pine.LNX.4.60.0407182231290.5181@agrippa.ukshells.co.uk> <16634.62725.795358.83767@cerise.nosuchdomain.co.uk>
Mime-Version 1.0 (Apple Message framework v619)
Content-Type text/plain; charset=US-ASCII; format=flowed
Message-Id <FC35B838-5124-11D9-AD97-000A95DB713E@charter.net>
Content-Transfer-Encoding 7bit
Cc grass5@grass.itc.it
From William K <woklist@charter.net>
Subject Re: [GRASS5] [bug #2544] (grass) grass libs built with paths to source tree, not install dir
Date Sat, 18 Dec 2004 12:45:27 -0600
To Request Tracker <grass-bugs@intevation.de>
X-Mailer Apple Mail (2.619)
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
After a bit of fiddling around, here is my current suggestion (I found 
the grass version strings, and recents changes fixed the missing 
cuserid problem):

	    SHLIB_CFLAGS="-fno-common"
	    SHLIB_LD="cc -dynamiclib -flat_namespace -compatibility_version 
\${GRASS_VERSION_MAJOR}.\${GRASS_VERSION_MINOR} -current_version 
\${GRASS_VERSION_MAJOR}.\${GRASS_VERSION_MINOR} -install_name 
\${LIB_RUNTIME_DIR}/lib\${LIB_NAME}\${SHLIB_SUFFIX}"

As long as the version strings are numbers this will work.  dylib 
versions can take a third number, but I left out GRASS_VERSION_RELEASE 
since it's 'cvs' right now.  If there was a third number it would be 
something like compatibility version = major.minor and current = 
major.minor.release.

My previous different SHLIB_LD's for Mac OS 10.2 and 10.3 can be 
ignored.

And, just to get it into the bug thread, while on linux embedding the 
path into the lib is bad (I'll take your word on that), on Mac OS X 
it's pretty much standard and possibly a requirement (since by default 
the linker embeds the build path, not the install path or none at all). 
  (Tho that does cause occassional build glitches when updating 
something.)

-----
William Kyngesburye <kyngchaos@charter.net>
http://webpages.charter.net/kyngchaos/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect


Sat, Jul 23 2005 05:15:04    Mail sent by kyngchaos@kyngchaos.com  
Return-Path <kyngchaos@kyngchaos.com>
Delivered-To grass-bugs@lists.intevation.de
X-IronPort-AV i="3.95,136,1120449600"; d="scan'208"; a="1338321034:sNHT15075548"
Mime-Version 1.0 (Apple Message framework v733)
Content-Transfer-Encoding 7bit
Message-Id <B5790E87-5DF1-4E15-AAD4-2F19BCF2683C@kyngchaos.com>
Content-Type text/plain; charset=US-ASCII; delsp=yes; format=flowed
To grass-bugs@intevation.de
From William Kyngesburye <kyngchaos@kyngchaos.com>
Subject re: [bug #2544] (grass) grass libs built with paths to source tree, not install dir
Date Fri, 22 Jul 2005 22:14:47 -0500
X-Mailer Apple Mail (2.733)
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
I just asked on the Mac OS X-UNIX porting list about this.  -install- 
name is a standard and normal and expected thing to do when creating  
a Mac dynamic library (the current/compability versions are optional,  
but a good idea).  In fact, versions of libtool back to at least  
1.3.x provide this functionality.  Mac OS X dynamic libraries use the  
mach-o format, not the linux elph format, and they expect a full path  
and name embedded in the library.  If one is not provided at build  
time, the default is embedded as the build location (ie in the source).

The patch has changed yet again.  I hope this doesn't become a  
regular occurrence.  Maybe attention should be paid to changing  
environment variables, and make sure the right ones are used (someone  
who knows the setup a little better could figure this out).   
Somewhere along the 6.1 CVS changes, LIB_RUNTIME_DIR changed (or  
disappeared), so it doesn't refer to the install library directory,  
and maybe LIB_RUNTIME_DIR wasn't the right choice in the first place.

Currently - this works for both 6.0 and 6.1 CVS - I have:

         SHLIB_CFLAGS="-fno-common"
         SHLIB_LD="cc -dynamiclib -flat_namespace - 
compatibility_version \${GRASS_VERSION_MAJOR}.\${GRASS_VERSION_MINOR}  
-current_version \${GRASS_VERSION_MAJOR}.\${GRASS_VERSION_MINOR} - 
install_name \${INST_DIR}/lib/lib\${LIB_NAME}\${SHLIB_SUFFIX}"

Note again that Mac OS library versions must only be integers, up to  
three dot-separated (ie major.minor.release for current, usually  
major.minor for compatibility).  Care should be taken that at least  
the major and minor versions are just numbers.  I left out the  
release version in the current-version, since in GRASS CVS versions  
this is a string, not a number.  Maybe some variable can be provided  
to specify an alternate format release version?  But that's not  
critical.


Sat, Jul 23 2005 13:22:06    Mail sent by msieczka  
William

Great that you care to manage your bugreports. But - if you want your comments
to be taken under consideration, please CC grass5@grass.itc.it and Folks who
you think might be helpfull and interested in the issue (delimit emails with
commas). Otherwise it might take infinity till somebody looks again into this
bugreport, epecially that it is assigned to 5.7 area, cause 'reply' and
'comment' in the bugtracker are not forwarded to the list automatically, shame.
Could you forward your remarks where applies?

Shall we change the bug assignation to 6.1?

Thanks for your help.

Cheers
Maciek
Sat, Jul 23 2005 17:26:30    Mail sent by kyngchaos@charter.net  
Return-Path <kyngchaos@charter.net>
Delivered-To grass-bugs@lists.intevation.de
X-IronPort-AV i="3.95,137,1120449600"; d="scan'208"; a="1178724994:sNHT32196824"
Mime-Version 1.0 (Apple Message framework v733)
In-Reply-To <20050723112206.F27851006B8@lists.intevation.de>
References <20050723112206.F27851006B8@lists.intevation.de>
Content-Type text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id <9D143FCC-3C7D-476F-BF4B-264446A3F81F@charter.net>
Content-Transfer-Encoding 7bit
From William Kyngesburye <kyngchaos@charter.net>
Subject Re: [bug #2544] (grass) grass libs built with paths to source tree, not install dir
Date Sat, 23 Jul 2005 10:26:18 -0500
To Maciek Sieczka via RT <grass-bugs@intevation.de>
X-Mailer Apple Mail (2.733)
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
On Jul 23, 2005, at 6:22 AM, Maciek Sieczka via RT wrote:

> William
>
> Great that you care to manage your bugreports. But - if you want  
> your comments
> to be taken under consideration, please CC grass5@grass.itc.it and  
> Folks who
> you think might be helpfull and interested in the issue (delimit  
> emails with
> commas). Otherwise it might take infinity till somebody looks again  
> into this
> bugreport, epecially that it is assigned to 5.7 area, cause 'reply'  
> and
> 'comment' in the bugtracker are not forwarded to the list  
> automatically, shame.
>
> Could you forward your remarks where applies?
>
> Shall we change the bug assignation to 6.1?
>
> Thanks for your help.
>
> Cheers
> Maciek
>
> -------------------------------------------- Managed by Request  
> Tracker
>

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect


Sat, Jul 23 2005 17:31:25    Mail sent by kyngchaos@charter.net  
Return-Path <kyngchaos@charter.net>
Delivered-To grass-bugs@lists.intevation.de
X-IronPort-AV i="3.95,137,1120449600"; d="scan'208"; a="1259548680:sNHT27506214"
Mime-Version 1.0 (Apple Message framework v733)
In-Reply-To <20050723112206.F27851006B8@lists.intevation.de>
References <20050723112206.F27851006B8@lists.intevation.de>
Content-Type text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id <58D42D20-4E69-4017-92E5-520C1B910E52@charter.net>
Content-Transfer-Encoding 7bit
From William Kyngesburye <kyngchaos@charter.net>
Subject Re: [bug #2544] (grass) grass libs built with paths to source tree, not install dir
Date Sat, 23 Jul 2005 10:31:16 -0500
To Maciek Sieczka via RT <grass-bugs@intevation.de>
X-Mailer Apple Mail (2.733)
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Sorry for that last one, I hit send before typing.  meant to go to  
list anyways.

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that  
the past isn't a fiction designed to account for the discrepancy  
between my immediate physical sensations and my state of mind?"

- The Ruler of the Universe


Thu, Aug 4 2005 17:40:29    Mail sent by mneteler  
This must be changed in aclocal.m4.

Working on that.

Markus
Thu, Aug 4 2005 17:40:39    Area changed to grass6 by mneteler  
Wed, Aug 31 2005 21:48:35    Mail sent by mneteler  
Hi,

I think that's resolved now.

Markus

Wed, Aug 31 2005 21:48:38    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