[prev in list] [next in list] [prev in thread] [next in thread] 

List:       icu-bugrfe
Subject:    Notification: incoming/1598
From:       jtcsv () jtcsv ! com
Date:       2001-12-26 17:20:44
[Download RAW message or body]

ICU bug tracking notification

new message incoming/1598

Message summary for PR#1598
	From: grhoten@jtcsv.com
	Subject: HP/UX seems to be linking against the libraries with the relative path
	Date: Wed, 26 Dec 2001 12:20:41 -0500 (EST)
	0 replies 	0 followups

====> ORIGINAL MESSAGE FOLLOWS <====

>From jtcsv  Wed Dec 26 12:20:42 2001
Received: by w1424.hostcentric.net (8.10.1/8.9.0) id fBQHKgJ18396
	for jtcsv; Wed, 26 Dec 2001 12:20:42 -0500 (EST)
Received: from localhost (w1424.hostcentric.net [66.40.230.254])
	by w1424.hostcentric.net (8.10.1/8.9.0) with ESMTP id fBQHKfj18391
	for <jtcsv@jtcsv.com>; Wed, 26 Dec 2001 12:20:41 -0500 (EST)
Date: Wed, 26 Dec 2001 12:20:41 -0500 (EST)
From: grhoten@jtcsv.com
Message-Id: <200112261720.fBQHKfj18391@w1424.hostcentric.net>
To: jtcsv@jtcsv.com
Subject: HP/UX seems to be linking against the libraries with the relative path

Full_Name: George Rhoten
Version: 200
OS: hpux
ICU_Component: config_build
project: ICU4C
Submission from: (NULL) (32.97.110.67)
Submitted by: grhoten


HP/UX seems to be linking against the libraries with the relative path.  This
may be fixed by using the libraries built with "make install".  If that is the
case, then this needs to go into the redistribution information.  However, this
problem may be due to HP/UX using something like rpath.  In that case, we should
fix it.  Here is the problem description from Martin Schneider from IBM
Germany.

Problem description

We compiled ICU 2.0 out-of-the-box without any changes. libicui18n.sl.20 is
linked against ../common/libicuuc.sl.20 . Unfortunely, this path (../common) is
burned into the library as the runtime search path which is also used during the
link step. This means that everytime you link against libicui18n.sl , the
dependent files are looked for in the relative directory ../common . (This will
also be the case for run time). However, in our build environment, we don't have
this path structure. 
We could not find any way to work around this problem. Here's what we tried: 

* set SHLIB_PATH during compile to enable lookup of dependent libs
* explicitly link against all dependent libs additionally to root lib
* explicitly indicate link time search path 
* use chatr on the lib files to change all relevant settings

Here the chatr output for the lib. 

$ chatr libicui18n.sl.20.0
libicui18n.sl.20.0: 
         shared library 
         shared library dynamic path search:
             SHLIB_PATH     enabled   first  
             embedded path  disabled  second Not Defined
         internal name:
             libicui18n.sl.20
         shared library list:
             dynamic   ../common/libicuuc.sl.20
             dynamic   ../stubdata/libicudt20b.sl
         static branch prediction disabled
         kernel assisted branch prediction enabled
         lazy swap allocation disabled
         text segment locking disabled
         data segment locking disabled
         data page size: D (default)
         instruction page size: D (default)

Is there I have missed or any solution that you know of?


[prev in list] [next in list] [prev in thread] [next in thread]