In message <aanlktimc0wjn_nry0cahjafd=delbzypp_mfgntt-...@mail.gmail.com>,
Charles Lee writes:
>
> see this:
> http://stackoverflow.com/questions/1023306/finding-current-executables-path-w
> ithout-proc-self-exe
>
> It seems a little different on FreeBSD.
I've reverted my change in r981763 so FreeBSD is already implemented.
We need implementations for Aix and z/OS. Unless anyone has more
specific AIX and/or z/OS implementations, then I think we should just
fall back to a solution like main_get_executable_name from:
classlib/modules/luni/src/main/native/launcher/unix/main_hlp.c
However reading this code it has several issues - like the pointless
directory changing in the !isSymbolicLink case and the use of
readSymbolicLink when realpath would be more appropriate - so I'd rather
fix it correctly then port the fixes back to the launcher (and portlib
hysysinfo.c IIRC).
Regards,
Mark.
> On Tue, Aug 3, 2010 at 10:24 AM, Regis <xu.re...@gmail.com> wrote:
>
> > On 2010-08-02 23:44, Daniel Gong wrote:
> >
> >> Hi all,
> >>
> >> As you know that I'm developing the jdb command line tool. I met a weird
> >> problem when building jdktools alone.
> >>
> >> Briefly, the problem is like this: after I build the jdktools module
> >> against
> >> hdk, each jdk tool command line tool turns out to be segmentation fault
> >> when
> >> running with a simple command such as "java", but succeeds when running
> >> with
> >> a full path such as "$HDK/jdk/bin/java".
> >>
> >> According to the component-wise instruction, I get the jdktools code and
> >> common resources code from svn, the directory structure is like this:
> >>
> >> myproject
> >> |
> >> |--------- jdktools
> >> | |
> >> | |---------- build.xml
> >> | |
> >> | |---------- LICENSE
> >> | |
> >> | |---------- make
> >> | |
> >> | |---------- modules
> >> | |
> >> | |---------- NOTICE
> >> |
> >> |--------- common resources
> >> | |
> >> | |---------- build.xml
> >> | |
> >> | |---------- depends
> >> | |
> >> | |---------- make
> >>
> >> And hdk is in another directory. HDK is also the java runtime that ant
> >> use.
> >>
> >> I have kept using the full path of jdk tool command to test whether my jdb
> >> works and tried to find a solution but still do not have one...
> >>
> >> Does any one know what happened? Thanks.
> >>
> >> Best wishes
> >> Daniel Gong
> >>
> >>
> > getExeDir in samsa.c uses realpath to find executable file path, which
> > can't handle case of executable file is in $PATH. Reading symbol link
> > "/proc/self/exe" can resolve it on linux, you can try following patch. I'm
> > not sure if it works on other platforms (AIX, z/OS).
> >
> > Index: jdktools/modules/samsa/src/main/native/samsa/samsa.c
> > =====================================================================
> > --- jdktools/modules/samsa/src/main/native/samsa/samsa.c
> > +++ jdktools/modules/samsa/src/main/native/samsa/samsa.c
> > @@ -471,13 +471,14 @@ char *getExeDir(const char* argv0) {
> >
> > // FIXME - handle this right - it could be that 512 isn't enough
> > #else
> > + int length;
> > char buffer[PATH_MAX + 1];
> >
> > - char *rc = realpath(argv0, buffer);
> > - if (!rc) {
> > - return NULL;
> > + length = readlink("/proc/self/exe", buffer, sizeof(buffer));
> > + if (length == -1) {
> > + return NULL;
> > }
> > - buffer[PATH_MAX] = '\0';
> > + buffer[length] = '\0';
> > #endif
> >
> > last = strrchr(buffer, PATH_SEPARATOR_CHAR);
> >
> >
> >
> > --
> > Best Regards,
> > Regis.
> >
>
>
>
> --
> Yours sincerely,
> Charles Lee
>
> --0015174beaa41f227f048ce43317--
>
