SEO

#1 (**permalink**) 01-17-2008, 06:00 AM

Hi,

In my application's 'lib' directory I notice that an additional file
is present with a # prefixed to it apart from the library I built and
other libraries. For eg: if my library is called mylib.sl, I see
another file #mylib.sl with the same ls -l entries as mylib.sl other
than of course the name. I suspect this might be getting created
during install because the depot which contains this .sl does not
contain the #prefixed version. Not really sure how it's created. The
problem is, my java code throws an unsatisfied link error and cannot
find this library although it can find some other libraries in the
same directory. It so happens that mylib.sl is the only library I
build and I only consume the other libraries. Removing this # prefixed
file and restarting my application does not help. Has anybody else
faced a similar issue? Wud greatly appreciate any help.

#2 (**permalink**) 01-17-2008, 06:00 AM

jrrtolkienfan@gmail.com writes:

> In my application's 'lib' directory I notice that an additional file
> is present with a # prefixed to it apart from the library I built and
> other libraries. For eg: if my library is called mylib.sl, I see
> another file #mylib.sl with the same ls -l entries as mylib.sl other
> than of course the name. I suspect this might be getting created
> during install because the depot which contains this .sl does not
> contain the #prefixed version. Not really sure how it's created.

This happens when swinstall finds that a file it is trying to
upgrade/overwrite is in use. It might happen also if swremove is
trying to remove a binary that is in use.

In both cases, I understand the kernel is holding a read lock (or
something like it) on the file, so any attempt to delete the file will
fail with "Text file busy" error. Renaming the file is allowed, so
swinstall/swremove will prefix the filename so that it's unlikely to
get used any more.

> The
> problem is, my java code throws an unsatisfied link error and cannot
> find this library although it can find some other libraries in the
> same directory. It so happens that mylib.sl is the only library I
> build and I only consume the other libraries. Removing this # prefixed
> file and restarting my application does not help. Has anybody else
> faced a similar issue? Wud greatly appreciate any help.

Too bad you did not specify your OS version (probably 11i, but is it
v1, v2 or v3?) nor architecture (PA-RISC or Itanium?).

Is your application's lib directory specified in the LD_LIBRARY_PATH
(if 64-bit) or SHLIB_PATH (if 32-bit) environment variable or in
/etc/dld.sl.conf file? ("man 5 dld.sl" for more information).

--
Matti.Kurkela@welho.com

#3 (**permalink**) 01-17-2008, 06:01 AM

On Jun 13, 9:16 pm, Matti Juhani Kurkela <Matti.Kurk...@welho.com>
wrote:
> jrrtolkien...@gmail.com writes:
> > In my application's 'lib' directory I notice that an additional file
> > is present with a # prefixed to it apart from thelibraryI built and
> > other libraries. For eg: if mylibraryis called mylib.sl, I see
> > another file #mylib.sl with the same ls -l entries as mylib.sl other
> > than of course the name. I suspect this might be getting created
> > during install because thedepotwhich contains this .sl does not
> > contain the #prefixed version. Not really sure how it's created.
>
> This happens when swinstall finds that a file it is trying to
> upgrade/overwrite is in use. It might happen also if swremove is
> trying to remove a binary that is in use.
>
> In both cases, I understand the kernel is holding a read lock (or
> something like it) on the file, so any attempt to delete the file will
> fail with "Text file busy" error. Renaming the file is allowed, so
> swinstall/swremove will prefix the filename so that it's unlikely to
> get used any more.
>
> > The
> >problemis, my java code throws an unsatisfied link error and cannot
> > find thislibraryalthough it can find some other libraries in the
> > same directory. It so happens that mylib.sl is the onlylibraryI
> > build and I only consume the other libraries. Removing this # prefixed
> > file and restarting my application does not help. Has anybody else
> > faced a similar issue? Wud greatly appreciate any help.
>
> Too bad you did not specify your OS version (probably 11i, but is it
> v1, v2 or v3?) nor architecture (PA-RISC or Itanium?).
>
> Is your application's lib directory specified in the LD_LIBRARY_PATH
> (if 64-bit) or SHLIB_PATH (if 32-bit) environment variable or in
> /etc/dld.sl.conf file? ("man 5 dld.sl" for more information).
>
> --
> Matti.Kurk...@welho.com

Hello,

Thanks for your reply

Turns out there was a problem with the JNI
code and no problems with the way the library was built or used nor
anything to do with the path not being set.

This is totally off topic but I have another weird problem now on HPUX
11.23 PA. Basically my application does a lot of graphing and it has a
JNI piece which it uses to get data from another application. Uses a
looot of RPC. While it seems to work fine on IA and solaris, on PA
prstat shows that the memory utilization does not increase very much
for the first graph but shoots up from abt 360k to abt 990k for the
second request and then the app crashes. We basically need to keep a
lot of data in memory but I don't c how it cud cause mem util to spike
this much. I tried drawing the same graph twice and the behavior is
the same. Also I'm pretty sure there are no major leaks which could
cause something like this to happen. Any idea what's happening?

Best Regards

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

SEO

library with # prefix getting created