WE SOLVE MORTGAGE PROBLEMS !!!
Specializing in loans for exceptional people
Self-Employed Borrowers
No Income or Asset Verification
All Levels of Credit Quality
Up to 100% Financing
High Debt Ratios
Non-Owner Occupied Properties
Renovation Plus Purchase and Re
Hello Albert,
> dependent on nothing:
> $ ldd libpng.so
> libz.so.2 => (file not found)
This is your problem. Your libpng.so is not self-contained.
The run-time linker is not able to resolve all dependencies
of your libpng.so. You may set LD_LIBRARY_PATH, but you
definetly want to fix yo
Huh? My experience (on Solaris) has been that if foo.so has an embedded RPATH
and the application bar uses foo.so and also has a RPATH, then the binary's
RPATH is used for shared lib lookups. If the RPATH of the binary does not
include the paths in the shared lib's RPATH, then the shared lib's d
On Wed, Dec 20, 2000 at 02:01:17PM -0500, Tom Kacvinsky wrote:
> Huh? My experience (on Solaris) has been that if foo.so has an
> embedded RPATH and the application bar uses foo.so and also has a
> RPATH, then the binary's RPATH is used for shared lib lookups. If
> the RPATH of the binary does n
On Wed, Dec 20, 2000 at 02:01:17PM -0500, Tom Kacvinsky wrote:
> Huh? My experience (on Solaris) has been that if foo.so has an embedded RPATH
> and the application bar uses foo.so and also has a RPATH, then the binary's
> RPATH is used for shared lib lookups. If the RPATH of the binary does not
> BTW, I posted the same message to comp.unix.solaris and it turns out
> there is a solution. In my code below, I dlopen libz.so and then
> libpng.so. This fails. libpng.so has a hard-coded dependency on
> libz.so.2. So, if I dlopen libz.so.2 and then libpng.so, everything
> works! Now, I don't th
On Wed, Dec 20, 2000 at 01:54:04PM -0600, Albert Chin-A-Young wrote:
> On Wed, Dec 20, 2000 at 02:01:17PM -0500, Tom Kacvinsky wrote:
> > Huh? My experience (on Solaris) has been that if foo.so has an
> > embedded RPATH and the application bar uses foo.so and also has a
> > RPATH, then the binary
On Wed, Dec 20, 2000 at 09:53:42PM +0100, Bjoern Fischer wrote:
> > BTW, I posted the same message to comp.unix.solaris and it turns out
> > there is a solution. In my code below, I dlopen libz.so and then
> > libpng.so. This fails. libpng.so has a hard-coded dependency on
> > libz.so.2. So, if I
ltconfig.in says:
osf3* | osf4* | osf5*)
version_type=osf
need_version=no
soname_spec='${libname}${release}.so'
library_names_spec='${libname}${release}.so$versuffix ${libname}${release}.so
libname.so'
shlibpath_var=LD_LIBRARY_PATH
sys_lib_search_path_spec="/usr/shlib /usr/ccs/lib /u
I am not so sure about this. From the man page for dlopen():
If other objects were link-edited with pathname when path-
name was built, that is, the pathname has dependencies on
other objects, those objects will automatically be loaded by
dlopen(). The directory search p
In regard to: Re: dlopen on Solaris compared with IRIX/Tru64, Albert...:
>Not all systems allow you to embed RPATH in a library. Tru64 UNIX 4.0D
>is one. I think libtool 1.4 and above allow you to embed RPATH.
Unless I misunderstand you, that's not correct:
05:04pm obelisk lib$odump -D /local/l
On Wed, Dec 20, 2000 at 05:09:48PM -0600, Tim Mooney wrote:
> In regard to: Re: dlopen on Solaris compared with IRIX/Tru64, Albert...:
>
> >Not all systems allow you to embed RPATH in a library. Tru64 UNIX 4.0D
> >is one. I think libtool 1.4 and above allow you to embed RPATH.
>
> Unless I misun
> once at process startup, and from a runpath setting within
> the object from which the call to dlopen() originated. These
> search rules will only be applied to path names that do not
> contain an embedded '/'. Objects whose names resolve to
[...]
> ... and from a
> "Patrick" == Patrick Guio <[EMAIL PROTECTED]> writes:
Patrick> I am not sure if this is to be adressed to libtool or maybe
Patrick> automake since the problem might come from depcom... Anyway
Patrick> I am trying to build a c++ library using libtool on a
Patrick> alphaev6-dec-osf5.0 using
Are you interested in Office 2000? I am selling perfectly working
copies
of Microsoft Office 2000 SR-1 Premium Edition for a flat price of
$50 USD.
The suite contains 4 discs and includes:
Word
Excel
Outlook
PowerPoint
Access
FrontPage
Publisher
Small Business Tools
PhotoDraw
Office
15 matches
Mail list logo
