date:20050706

Re: Using a logitech mx700 with scrollwheel _and_ thumb buttons

2005-07-06 Thread Joe Schmoe

Andre,

--- André-Philippe Paquet <[EMAIL PROTECTED]> wrote:

> My MX500 is working just fine. Here what I do:
> 
>- Install imwheel (/usr/ports/x11/imwheel) 
> 
> 
>- Add this to ~/.imwheelrc 
> 
> ".*"
> None, Up, Alt_L|Left,1
> None, Down, Alt_L|Right,1
> 
> "(null)"
> None, Up, Alt_L|Left,1
> None, Down, Alt_L|Right,1
>  
> 
>- In my x.org  file.. For the
> InputDevice section: 
> 
> Option "Buttons" "7"
> Option "ZAxisMapping" "6 7"
>  
>- Finaly, I run these two commands on Xwindows
> start: 
> 
> imwheel -b "67" &
> xmodmap -e "pointer = 1 2 3 6 7 4 5"

Nope.  I reproduced these same settings _exactly_, and
they produce the same results.

With your settings above, the scroll wheel works fine,
and the two thumb buttons each cause the web page to
scroll very slightly downward.  This is the same thing
they did with all the other different configurations I
tried.

Why is using mouse thumb buttons under FreeBSD _rocket
science_ ?  Why is this a _hard problem_ ?

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

logitech mx700 mouse button disfunction under FreeBSD

2005-07-06 Thread Joe Schmoe

The logitech mx700 is a cordless 10-button mouse (3
buttons, two thumb buttons, scroll wheel up and down,
two paging buttons, and one "app" button).

While the mx500 mouse, that seems to be very closely
related to the mx700, has been reported to work
(scroll wheel and both thumb buttons function) under
FreeBSD, and while the mx700 is working in the same
fashion under linux, the mx700 _does not_ function
under FreeBSD.

Details:

Using this configuration in your X/Xorg configuration
file:

Section "InputDevice"
Identifier  "Mouse0"
Driver  "mouse"
Option  "Protocol" "auto"
Option  "Device" "/dev/sysmouse"
Option  "Buttons" "7"
Option  "ZAxisMapping" "6 7"
EndSection

along with these startup options for X/Xorg:

/usr/X11R6/bin/xmodmap -e "pointer = 1 2 3 6 7 4 5"
/usr/X11R6/bin/imwheel -b "67" &

and these settings in ~/.imwheelrc :

".*"
None, Up, Alt_L|Left,1
None, Down, Alt_L|Right,1

"(null)"
None, Up, Alt_L|Left,1
None, Down, Alt_L|Right,1

You will end up with the three standard buttons
functioning, and the scrollwheel functioning (as
buttons events 4 and 5).  Further, the page up and
down buttons will simply send double-4 and double-5
button events.

However, the other three buttons (thumbs and app
button) will _all send button event 5_.

I have tried every conceivable combination of
Zaxismapping, xmodmap settings, and with and without
imwheel ... no matter what, the three final buttons
(two thumbs and one app button) always produce the
same button event.  Even if you configure 9 or 10
buttons in your X config.  Those three buttons will
ALWAYS send the same button event.

So what is the reason for this ?  Why does the mx500
function and the mx700 does not ?

More importantly, what is a strategy for getting to
the bottom of this and fixing it ?  If you look at the
mailing list archives, there are many, many examples
of people going through this same hell and just giving
up.

Comments ?

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Using a logitech mx700 with scrollwheel _and_ thumb buttons

2005-07-06 Thread André-Philippe Paquet

Sorry, I didn't see your last message! Start xwindows with your favorite wm 
and in a terminal, run:
imwheel -b "67" &
xmodmap -e "pointer = 1 2 3 6 7 4 5"

 If it doesn't work, it may be something else. I just redid the whole 
process I told and it works here.

Andre-Philippe
On 7/5/05, Joe Schmoe <[EMAIL PROTECTED]> wrote:
> 
> 
> Andre,
> 
> --- André-Philippe Paquet <[EMAIL PROTECTED]> wrote:
> 
> > My MX500 is working just fine. Here what I do:
> >
> > - Install imwheel (/usr/ports/x11/imwheel)
> >
> >
> > - Add this to ~/.imwheelrc
> >
> > ".*"
> > None, Up, Alt_L|Left,1
> > None, Down, Alt_L|Right,1
> >
> > "(null)"
> > None, Up, Alt_L|Left,1
> > None, Down, Alt_L|Right,1
> >
> >
> > - In my x.org   file.. For the
> > InputDevice section:
> >
> > Option "Buttons" "7"
> > Option "ZAxisMapping" "6 7"
> >
> > - Finaly, I run these two commands on Xwindows
> > start:
> >
> > imwheel -b "67" &
> > xmodmap -e "pointer = 1 2 3 6 7 4 5"
> 
> 
> Nope. I reproduced these same settings _exactly_, and
> they produce the same results.
> 
> With your settings above, the scroll wheel works fine,
> and the two thumb buttons each cause the web page to
> scroll very slightly downward. This is the same thing
> they did with all the other different configurations I
> tried.
> 
> Why is using mouse thumb buttons under FreeBSD _rocket
> science_ ? Why is this a _hard problem_ ?
> 
> __
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Call for FreeBSD status reports

2005-07-06 Thread Max Laier

All,

Three month of fruitful development have passed since the last round of 
FreeBSD status reports, and the release of FreeBSD 6.0 is on the 
doorstep.  We hope that you made good progress on your projects and have 
interesting news to share.  Please do so by sending a status report to 
[EMAIL PROTECTED]  Submissions are due by July 15, 2005.

Reports should cover activities during May to June, but may of course cover 
earlier work as well.  In addition we encourage you to use the "Open Tasks" 
section to recruit help for your project and point out future direction.

Submissions are *not* limited to FreeBSD developers with commit rights!  It is 
open to everybody who is doing FreeBSD related work and wants to share 
progress with the community.  The status reports are also a good vehicle to 
gather interested people for you WIP.

We have introduced a new category called "soc" to pool reports related to 
Google Summer of Code.  We hope for interesting news from that corner!

To help you with fileing your report you will find a webform or xml-template 
linked from http://www.freebsd.org/news/status/ (as soon as the www build 
completes).

Submissions are due on July 15.  Thanks a lot, and we are hoping for a big 
turn-out.

-- 
/"\  Best regards,  | [EMAIL PROTECTED]
\ /  Max Laier  | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | [EMAIL PROTECTED]
/ \  ASCII Ribbon Campaign  | Against HTML Mail and News


pgp7bIJEEAJ4k.pgp
Description: PGP signature

Re: linking libjava.so RPATH problem

2005-07-06 Thread Tom Schutter

On 7/5/05, Vasil Dimov <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 05, 2005 at 03:55:26PM -0600, Tom Schutter wrote:
> > I am having problems linking in the Java JVM libraries (libjava.so,
> > libverify.so, libjvm.so) into my executable.
> >
> > With these options added to my gcc command:
> >  -L/usr/local/jdk1.4.2/jre/lib/i386 -ljava -lverify
> >  -L/usr/local/jdk1.4.2/jre/lib/i386/server -ljvm
> >
> > It links ok, but when I try to run it I get:
> > $ ./testme
> > /libexec/ld-elf.so.1: Shared object "libjava.so" not found, required by
> > "testme"
> >
> > At this point ldd tells me:
> > $ ldd testme
> > testme:
> >libm.so.3 =3D> /lib/libm.so.3 (0x2807c000)
> >libjava.so =3D> not found (0x0)
> >libverify.so =3D> not found (0x0)
> >libjvm.so =3D> not found (0x0)
> >libpthread.so.1 =3D> /usr/lib/libpthread.so.1 (0x28097000)
> >libc.so.5 =3D> /lib/libc.so.5 (0x280bb000)
> >
> > Using -Xlinker -rpath -Xlinker PATH_TO_JRE_DIR, I can tell my executable to
> > look in the JRE dir for libjvm.so.  I have verified that RPATH has been set
> > in the executable using objdump:
> > $ objdump -x testme | grep RPATH
> >  RPATH   
> > /usr/local/jdk1.4.2/jre/lib/i386:/usr/local/jdk1.4.2/jre/lib/i386/server
> >
> > But when I run the executable, it cannot find libjvm.so:
> > $ ./testme
> > /libexec/ld-elf.so.1: Shared object "libjvm.so" not found, required by
> > "libjava.so"
> >
> > At this point ldd tells me:
> > $ ldd ./testme
> > ./testme:
> >libm.so.3 =3D> /lib/libm.so.3 (0x2807c000)
> >libjava.so =3D> /usr/local/jdk1.4.2/jre/lib/i386/libjava.so 
> > (0x28097000)
> >libverify.so =3D> /usr/local/jdk1.4.2/jre/lib/i386/libverify.so
> > (0x280b5000)
> >libjvm.so =3D>
> > /usr/local/jdk1.4.2/jre/lib/i386/server/libjvm.so (0x280ca000)
> >libpthread.so.1 =3D> /usr/lib/libpthread.so.1 (0x28702000)
> >libc.so.5 =3D> /lib/libc.so.5 (0x28726000)
> >libjvm.so =3D> not found (0x0)
> >libverify.so =3D> not found (0x0)
> >libjvm.so =3D> not found (0x0)
> >libstdc++.so.4 =3D> /usr/lib/libstdc++.so.4 (0x2880)
> >
> > Note that at this point on Linux, testme runs ok.
> >
> > If I set LD_LIBRARY_PATH, the libraries are found (no output is correct):
> > $ 
> > LD_LIBRARY_PATH=3D/usr/local/jdk1.4.2/jre/lib/i386:/usr/local/jdk1.4.2/jre/lib/i386/server
> > ./testme
> > $
> >
> > My questions are:
> >
> > 1) Why is the RPATH in the executable being ignored?
> 
> Here are my suggestions:
> 
> It is not being ignored, as you see: libjava.so, libverify.so and
> libjvm.so were found in /usr/local/jdk1.4.2/jre/lib/i386/
> 
> > 2) When I add the -rpath, I get two copies of a libjvm.so reference in 
> > testme,
> >   one that resolves correctly, and one that doesn't.  Why?
> 
> What happens is that libjava.so "depends" on libjvm.so and libverify.so
> itself:
> % ldd /usr/local/jdk1.4.2/jre/lib/i386/libjava.so
> /usr/local/jdk1.4.2/jre/lib/i386/libjava.so:
> libjvm.so => not found (0x0)
> libverify.so => not found (0x0)
> 
> and libverify.so "depends" on libjvm.so itself:
> % ldd /usr/local/jdk1.4.2/jre/lib/i386/libverify.so
> /usr/local/jdk1.4.2/jre/lib/i386/libverify.so:
> libjvm.so => not found (0x0)
> 
> So, after finding libjava.so, libverify.so and libjvm.so, required by
> "testme" executable (thanks to its RPATH) the linker sees that
> libjava.so itself depends on libjvm.so and libverify.so and:
> 1. does not notice that they are already found/loaded
> 2. does not use the rpath in "testme"
> 3. starts looking for them in the standard path and does not find them
> 
> > 3) What is the correct way of linking in libjvm.so?
> 
> In my point of view the libjava.so and libverify.so shared objects are
> incorrect in the way that they depend on some shared objects, that are
> not located in the standard path *AND* libjava.so and libverify.so do
> not have RPATH in themselves.
> 
> 1. Recompile libjava.so and libverify.so without -L... -l..., it is not
> needed anyway.
> OR
> 2. Recompile libjava.so and libverify.so with -L... -l..., but also add
> -rpath
> OR
> 3. Use ldconfig -m (see ldconfig_paths in rc.conf(5))
> OR
> 4. Use LD_LIBRARY_PATH
> 
> > Thanks,
> > --
> > Tom Schutter

This is making more sense now.

1) Does the fact that the linker does not realize that the libraries
have already been found indicate a bug in the linker?  If so, how do I
best report it?

2) Because libjava.so and libverify.so were compiled by the java/jdk14
port, your suggestions on recompiling those libraries should be done
within that framework.  (This part is for you Alexey).

3) For now, I will try using ldconfig, but I think that the better
solution is to fix the creation of the shared libraries.

-- 
Tom Schutter
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

bus error in strsep

2005-07-06 Thread Stefan Sperling

Hello hackers,

I am getting a bus error in my application when I call strsep
and it matches a character. It doesn't matter whether I call
the strsep from my libc or a freshly compiled one, the error
stays the same.

This is my test case:

$ cat strsep.c

#define NULL ((void*)0)

/* copied verbatim from /usr/src/lib/libc/string/strsep.c,
 * except for the name change
 */
char *
mystrsep(stringp, delim)
char **stringp;
const char *delim;
{
char *s;
const char *spanp;
int c, sc;
char *tok;

if ((s = *stringp) == NULL)
return (NULL);
for (tok = s;;) {
c = *s++;
spanp = delim;
do {
if ((sc = *spanp++) == c) {
if (c == 0)
s = NULL;
else
s[-1] = 0;
*stringp = s;
return (tok);
}
} while (sc != 0);
}
/* NOTREACHED */
}

int main(int argc, char* argv[])
{
char *c = "whats:your:name:buddy?";
(void*)mystrsep(&c, ":");
}

$ gcc -g -o strsep strsep.c
$ gdb strsep

(gdb) run
Starting program: /home/stsp/test/strsep

Program received signal SIGBUS, Bus error.
0x080484f2 in mystrsep (stringp=0xbfbfea34, delim=0x80485e6 ":") at strsep.c:26
26  s[-1] = 0;
(gdb) print s[-1]
$1 = 58 ':'
(gdb)

When I single step through mystrsep the program works fine.

I am running FreeBSD-current from 17th June 2005 on an Athlon-XP,
no SMP involved. I can reproduce the error on a dual Celeron box
running FreeBSD-5.4-RELEASE with SMP.
And I also get the same error with similar code using strtok.

Can anyone else reproduce this?

thanks a lot,
-- 
stefan
http://stsp.in-berlin.de PGP Key: 0xF59D25F0
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: bus error in strsep

2005-07-06 Thread Maksim Yevmenkin


Stefan,


int main(int argc, char* argv[])
{
char *c = "whats:your:name:buddy?";
 that is not read only copy. you can not write 
into it. replace it with


char *c = strdup("whats:your:name:buddy?");

(void*)mystrsep(&c, ":");
}



and it should work.

thanks,
max
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: bus error in strsep

2005-07-06 Thread Maksim Yevmenkin


Maksim Yevmenkin wrote:

Stefan,


int main(int argc, char* argv[])
{
char *c = "whats:your:name:buddy?";


 that is not read only copy. you can not write into it. 
replace it with


made type. that should read "that is read only copy" :)



char *c = strdup("whats:your:name:buddy?");


(void*)mystrsep(&c, ":");
}



and it should work.

thanks,
max



___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: bus error in strsep

2005-07-06 Thread Stefan Sperling

On Wed, Jul 06, 2005 at 12:10:23PM -0700, Maksim Yevmenkin wrote:
> Maksim Yevmenkin wrote:
> >>char *c = "whats:your:name:buddy?";
> >
> > that is not read only copy. you can not write 
> >into it. replace it with
> 
> made type. that should read "that is read only copy" :)

Dark corners of C... So it's my own fault, as usual :)
thanks a lot :)
-- 
stefan
http://stsp.in-berlin.de PGP Key: 0xF59D25F0
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: bus error in strsep

2005-07-06 Thread Dimitry Andric

On 2005-07-06 at 21:41:00 Stefan Sperling wrote:

>> >>char *c = "whats:your:name:buddy?";
>> made type. that should read "that is read only copy" :)
> Dark corners of C... So it's my own fault, as usual :)

Actually, this dark corner was enlightened not so long ago.  String
constants used to be writable for years, until someone decided that it
was better not to. :)

Anyway, you can get the old (deprecated!) behaviour by using the
-fwritable-strings option to gcc.

pgpOjDCRlF0Rw.pgp
Description: PGP signature

Re: Using a logitech mx700 with scrollwheel _and_ thumb buttons

2005-07-06 Thread Julian Elischer




Joe Schmoe wrote:


Andre,

--- André-Philippe Paquet <[EMAIL PROTECTED]> wrote:

 


My MX500 is working just fine. Here what I do:

  - Install imwheel (/usr/ports/x11/imwheel) 



  - Add this to ~/.imwheelrc 


".*"
None, Up, Alt_L|Left,1
None, Down, Alt_L|Right,1

"(null)"
None, Up, Alt_L|Left,1
None, Down, Alt_L|Right,1


  - In my x.org  file.. For the
InputDevice section: 


Option "Buttons" "7"
Option "ZAxisMapping" "6 7"

  - Finaly, I run these two commands on Xwindows
start: 


imwheel -b "67" &
xmodmap -e "pointer = 1 2 3 6 7 4 5"
   




Nope.  I reproduced these same settings _exactly_, and
they produce the same results.

With your settings above, the scroll wheel works fine,
and the two thumb buttons each cause the web page to
scroll very slightly downward.  This is the same thing
they did with all the other different configurations I
tried.

Why is using mouse thumb buttons under FreeBSD _rocket
science_ ?  Why is this a _hard problem_ ?
 


because no-one who has the interest in fixing it has the time
to do so and visa versa.


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___

freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
 


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: bus error in strsep

2005-07-06 Thread Giorgos Keramidas

On 2005-07-06 12:08, Maksim Yevmenkin <[EMAIL PROTECTED]> wrote:
> Stefan,
>
> >int main(int argc, char* argv[])
> >{
> > char *c = "whats:your:name:buddy?";
>  that is not read only copy. you can not write
> into it. replace it with
>
> char *c = strdup("whats:your:name:buddy?");

Or the following:

char c[] = "whats:your:name:buddy?";

which doesn't require a free() operation when you're done with c[].

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: bus error in strsep

2005-07-06 Thread Maksim Yevmenkin


int main(int argc, char* argv[])
{
char *c = "whats:your:name:buddy?";


    that is not read only copy. you can not write
into it. replace it with

   char *c = strdup("whats:your:name:buddy?");


Or the following:

char c[] = "whats:your:name:buddy?";

which doesn't require a free() operation when you're done with c[].


actually it still will crash :)

beetle% cat 5.c
#include 

int
main(int argc, char* argv[])
{
char c[] = "whats:your:name:buddy?";
strsep((char **) &c, ":");
return (0);
}

beetle% gcc -Wall -ggdb 5.c
beetle% ./a.out
Segmentation fault (core dumped)

so something like this

#include 

int
main(int argc, char* argv[])
{
char c[] = "whats:your:name:buddy?", *s = c;
strsep((char **) &s, ":");
return (0);
}

will work too.

max
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: thread-safe popen

2005-07-06 Thread Dipjyoti Saikia

Hi ,

Please find the code snippet of popen() from the source code that I
have (We are working on an OS that is derived from FreeBSD 4.1) . I
don't think I have the thread safe version .

-

FILE *
popen(command, type)
const char *command, *type;
{
struct pid *cur;
FILE *iop;
int pdes[2], pid, twoway;
char *argv[4];
struct pid *p;

/*
 * Lite2 introduced two-way popen() pipes using socketpair().
 * FreeBSD's pipe() is bidirectional, so we use that.
 */
if (strchr(type, '+')) {
twoway = 1;
type = "r+";
} else  {
twoway = 0;
if ((*type != 'r' && *type != 'w') || type[1])
return (NULL);
}
if (pipe(pdes) < 0)
return (NULL);

if ((cur = malloc(sizeof(struct pid))) == NULL) {
(void)_close(pdes[0]);
(void)_close(pdes[1]);
return (NULL);
}

argv[0] = "sh";
argv[1] = "-c";
argv[2] = (char *)command;
argv[3] = NULL;


switch (pid = vfork()) {
case -1:/* Error. */
(void)_close(pdes[0]);
(void)_close(pdes[1]);
free(cur);
return (NULL);
/* NOTREACHED */
case 0: /* Child. */
if (*type == 'r') {
/*
 * The dup2() to STDIN_FILENO is repeated to avoid
 * writing to pdes[1], which might corrupt the
 * parent's copy.  This isn't good enough in
 * general, since the _exit() is no return, so
 * the compiler is free to corrupt all the local
 * variables.
 */
(void)_close(pdes[0]);
if (pdes[1] != STDOUT_FILENO) {
(void)dup2(pdes[1], STDOUT_FILENO);
(void)_close(pdes[1]);
if (twoway)
(void)dup2(STDOUT_FILENO, STDIN_FILENO);
} else if (twoway && (pdes[1] != STDIN_FILENO))
(void)dup2(pdes[1], STDIN_FILENO);
} else {
if (pdes[0] != STDIN_FILENO) {
(void)dup2(pdes[0], STDIN_FILENO);
(void)_close(pdes[0]);
}
(void)_close(pdes[1]);
}
for (p = pidlist; p; p = p->next) {
(void)_close(fileno(p->fp));
}
execve(_PATH_BSHELL, argv, environ);
_exit(127);
/* NOTREACHED */
}

  ---
  

}
--

We  had cases where our RAID applications (multi-threaded )  failed 
with invocations of popen() .  Initially we  handpicked the popen()
calls and replaced it with actual code of the functions but it was
simply too much work and little gain .

So we decided to backport a thread-safe version . (If the above code
is not thread-safe then we will have a bigger problem at hand .)

--Dip



On 7/5/05, Dan Nelson <[EMAIL PROTECTED]> wrote:
> In the last episode (Jul 05), Dipjyoti Saikia said:
> > I am working on an OS derived for BSD 4.1 .  I am trying to backport
> > a thread-safe version of popen() from BSD 4.10 .
> 
> popen should be threadsafe as of rev 1.17 (2003-01-03) of
> /usr/src/lib/libc/gen/popen.c .  It was merged into the 4.* branch in
> rev 1.14.2.1 (2004/12/15).  The PR is bin/50770 .  Do you have a
> testcase that causes it to fail?
> 
> --
>Dan Nelson
>[EMAIL PROTECTED]
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: linking libjava.so RPATH problem

2005-07-06 Thread Vasil Dimov

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Jul 06, 2005 at 10:29:20AM -0600, Tom Schutter wrote:
> On 7/5/05, Vasil Dimov <[EMAIL PROTECTED]> wrote:
> > On Tue, Jul 05, 2005 at 03:55:26PM -0600, Tom Schutter wrote:
> > > I am having problems linking in the Java JVM libraries (libjava.so,
> > > libverify.so, libjvm.so) into my executable.
> > >
> > > With these options added to my gcc command:
> > >  -L/usr/local/jdk1.4.2/jre/lib/i386 -ljava -lverify
> > >  -L/usr/local/jdk1.4.2/jre/lib/i386/server -ljvm
> > >
> > > It links ok, but when I try to run it I get:
> > > $ ./testme
> > > /libexec/ld-elf.so.1: Shared object "libjava.so" not found, required by
> > > "testme"
> > >
> > > At this point ldd tells me:
> > > $ ldd testme
> > > testme:
> > >libm.so.3 =3D> /lib/libm.so.3 (0x2807c000)
> > >libjava.so =3D> not found (0x0)
> > >libverify.so =3D> not found (0x0)
> > >libjvm.so =3D> not found (0x0)
> > >libpthread.so.1 =3D> /usr/lib/libpthread.so.1 (0x28097000)
> > >libc.so.5 =3D> /lib/libc.so.5 (0x280bb000)
> > >
> > > Using -Xlinker -rpath -Xlinker PATH_TO_JRE_DIR, I can tell my executable 
> > > to
> > > look in the JRE dir for libjvm.so.  I have verified that RPATH has been 
> > > set
> > > in the executable using objdump:
> > > $ objdump -x testme | grep RPATH
> > >  RPATH   
> > > /usr/local/jdk1.4.2/jre/lib/i386:/usr/local/jdk1.4.2/jre/lib/i386/server
> > >
> > > But when I run the executable, it cannot find libjvm.so:
> > > $ ./testme
> > > /libexec/ld-elf.so.1: Shared object "libjvm.so" not found, required by
> > > "libjava.so"
> > >
> > > At this point ldd tells me:
> > > $ ldd ./testme
> > > ./testme:
> > >libm.so.3 =3D> /lib/libm.so.3 (0x2807c000)
> > >libjava.so =3D> /usr/local/jdk1.4.2/jre/lib/i386/libjava.so 
> > > (0x28097000)
> > >libverify.so =3D> /usr/local/jdk1.4.2/jre/lib/i386/libverify.so
> > > (0x280b5000)
> > >libjvm.so =3D>
> > > /usr/local/jdk1.4.2/jre/lib/i386/server/libjvm.so (0x280ca000)
> > >libpthread.so.1 =3D> /usr/lib/libpthread.so.1 (0x28702000)
> > >libc.so.5 =3D> /lib/libc.so.5 (0x28726000)
> > >libjvm.so =3D> not found (0x0)
> > >libverify.so =3D> not found (0x0)
> > >libjvm.so =3D> not found (0x0)
> > >libstdc++.so.4 =3D> /usr/lib/libstdc++.so.4 (0x2880)
> > >
> > > Note that at this point on Linux, testme runs ok.
> > >
> > > If I set LD_LIBRARY_PATH, the libraries are found (no output is correct):
> > > $ 
> > > LD_LIBRARY_PATH=3D/usr/local/jdk1.4.2/jre/lib/i386:/usr/local/jdk1.4.2/jre/lib/i386/server
> > > ./testme
> > > $
> > >
> > > My questions are:
> > >
> > > 1) Why is the RPATH in the executable being ignored?
> > 
> > Here are my suggestions:
> > 
> > It is not being ignored, as you see: libjava.so, libverify.so and
> > libjvm.so were found in /usr/local/jdk1.4.2/jre/lib/i386/
> > 
> > > 2) When I add the -rpath, I get two copies of a libjvm.so reference in 
> > > testme,
> > >   one that resolves correctly, and one that doesn't.  Why?
> > 
> > What happens is that libjava.so "depends" on libjvm.so and libverify.so
> > itself:
> > % ldd /usr/local/jdk1.4.2/jre/lib/i386/libjava.so
> > /usr/local/jdk1.4.2/jre/lib/i386/libjava.so:
> > libjvm.so => not found (0x0)
> > libverify.so => not found (0x0)
> > 
> > and libverify.so "depends" on libjvm.so itself:
> > % ldd /usr/local/jdk1.4.2/jre/lib/i386/libverify.so
> > /usr/local/jdk1.4.2/jre/lib/i386/libverify.so:
> > libjvm.so => not found (0x0)
> > 
> > So, after finding libjava.so, libverify.so and libjvm.so, required by
> > "testme" executable (thanks to its RPATH) the linker sees that
> > libjava.so itself depends on libjvm.so and libverify.so and:
> > 1. does not notice that they are already found/loaded
> > 2. does not use the rpath in "testme"
> > 3. starts looking for them in the standard path and does not find them
> > 
> > > 3) What is the correct way of linking in libjvm.so?
> > 
> > In my point of view the libjava.so and libverify.so shared objects are
> > incorrect in the way that they depend on some shared objects, that are
> > not located in the standard path *AND* libjava.so and libverify.so do
> > not have RPATH in themselves.
> > 
> > 1. Recompile libjava.so and libverify.so without -L... -l..., it is not
> > needed anyway.
> > OR
> > 2. Recompile libjava.so and libverify.so with -L... -l..., but also add
> > -rpath
> > OR
> > 3. Use ldconfig -m (see ldconfig_paths in rc.conf(5))
> > OR
> > 4. Use LD_LIBRARY_PATH
> > 
> > > Thanks,
> > > --
> > > Tom Schutter
> 
> This is making more sense now.
> 
> 1) Does the fact that the linker does not realize that the libraries
> have already been found indicate a bug in the linker?  If so, how do I
> best report it?

I cannot think of any sensible reason for this behavior, so I guess it
would be good if it can be "fixed" without breaking something else :)
You best report it by creating a patc

Re: Using a logitech mx700 with scrollwheel _and_ thumb buttons

logitech mx700 mouse button disfunction under FreeBSD

Re: Using a logitech mx700 with scrollwheel _and_ thumb buttons

Call for FreeBSD status reports

Re: linking libjava.so RPATH problem

bus error in strsep

Re: bus error in strsep

Re: bus error in strsep

Re: bus error in strsep

Re: bus error in strsep

Re: Using a logitech mx700 with scrollwheel _and_ thumb buttons

Re: bus error in strsep

Re: bus error in strsep

Re: thread-safe popen

Re: linking libjava.so RPATH problem

15 matches

Site Navigation

Mail list logo

Footer information