VW 7.7.1 on Linux 32

> We have an application that uses an external "C" library. Our
> subclass of ExternalInterface is CPOKTestInterface. In the definition
> of CPOKTestInterface, the libraryFiles attribute is set to the name
> of the shared library, the libraryDirectories is set to an
> environmental variable holding the directory path to the shared
> library. We've been using this techniques since we started using VW
> at about  version 2.5 on DecUnix platforms. Our main development
> platform now is Windows, currently XP, 32 bit. We are expanding to
> include Linux 32 and 64 bit platforms. This technique worked with the
> VW 7.5 engine on all three platforms. It works on Windows and Linux
> 64 (Red Hat) with the VW7.7.1 engine but not on the Linux 32 platform
> (Debian).
>
> On Linux 32, when I try to call a function in the shared library, I
> get an error indicating that the method call is unlinked
> (ExternalMethod>>unlinkedCall:arguments: and eventually a
> primLibraryLoad error). The environmental variable is set to point to
> the correct directory. Running nm -u on the shared library produces
> the same output as the library in the VW 7.5 version, so I think I
> have every thing defined.  I can run my application's previous
> version's image file with the VW 7.5 engine and the environmental
> variable pointing to the "new" shared library and it works fine. So I
> think the library is OK. I just can't get VW 7.7.1 engine to see it.
>
>
> Ideas?
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

> On Linux 32, when I try to call a function in the shared library, I
> get an error indicating that the method call is unlinked
> (ExternalMethod>>unlinkedCall:arguments: and eventually a
> primLibraryLoad error). The environmental variable is set to point to
> the correct directory. Running nm -u on the shared library produces
> the same output as the library in the VW 7.5 version, so I think I
> have every thing defined.  I can run my application's previous
> version's image file with the VW 7.5 engine and the environmental
> variable pointing to the "new" shared library and it works fine. So I
> think the library is OK. I just can't get VW 7.7.1 engine to see it.
>
>
> Ideas?
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

> Of Jim Harsh
> Sent: Wednesday, February 16, 2011 4:36 PM
> To: [hidden email]
> Subject: [vwnc] VW 7.7.1 on Linux 32
>
> We have an application that uses an external "C" library. Our
> subclass of ExternalInterface is CPOKTestInterface. In the definition
> of CPOKTestInterface, the libraryFiles attribute is set to the name
> of the shared library, the libraryDirectories is set to an
> environmental variable holding the directory path to the shared
> library. We've been using this techniques since we started using VW
> at about  version 2.5 on DecUnix platforms. Our main development
> platform now is Windows, currently XP, 32 bit. We are expanding to
> include Linux 32 and 64 bit platforms. This technique worked with the
> VW 7.5 engine on all three platforms. It works on Windows and Linux
> 64 (Red Hat) with the VW7.7.1 engine but not on the Linux 32 platform
> (Debian).
>
> On Linux 32, when I try to call a function in the shared library, I
> get an error indicating that the method call is unlinked
> (ExternalMethod>>unlinkedCall:arguments: and eventually a
> primLibraryLoad error). The environmental variable is set to point to
> the correct directory. Running nm -u on the shared library produces
> the same output as the library in the VW 7.5 version, so I think I
> have every thing defined.  I can run my application's previous
> version's image file with the VW 7.5 engine and the environmental
> variable pointing to the "new" shared library and it works fine. So I
> think the library is OK. I just can't get VW 7.7.1 engine to see it.
>
>
> Ideas?
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

>A couple things to try, just in case they yield useful information.
>Regarding the libraryDirectories attribute, what happens if you ignore
>the env variable name, and replace it temporarily with the actual path
>where the shared lives? This should certainly work, and if it doesn't,
>that's interesting.
>
>The other thing to note is that your shared library may depend on
>another shared, and perhaps that shared can't be found (or loaded),
>which prevents your intended shared library from loading. Even though it
>all works in vw7.5, maybe that other shared is somehow accessible to
>your vw7.5 image (eg., in its image directory).
>
>The second one is reaching a bit, but I think the failure to load looks
>the same whether it's the primary shared, or one of its dependents
>causing the problem.
>
>- Dave
>
> > -----Original Message-----
> > From: [hidden email] [mailto:[hidden email]] On
>Behalf
> > Of Jim Harsh
> > Sent: Wednesday, February 16, 2011 4:36 PM
> > To: [hidden email]
> > Subject: [vwnc] VW 7.7.1 on Linux 32
> >
> > We have an application that uses an external "C" library. Our
> > subclass of ExternalInterface is CPOKTestInterface. In the definition
> > of CPOKTestInterface, the libraryFiles attribute is set to the name
> > of the shared library, the libraryDirectories is set to an
> > environmental variable holding the directory path to the shared
> > library. We've been using this techniques since we started using VW
> > at about  version 2.5 on DecUnix platforms. Our main development
> > platform now is Windows, currently XP, 32 bit. We are expanding to
> > include Linux 32 and 64 bit platforms. This technique worked with the
> > VW 7.5 engine on all three platforms. It works on Windows and Linux
> > 64 (Red Hat) with the VW7.7.1 engine but not on the Linux 32 platform
> > (Debian).
> >
> > On Linux 32, when I try to call a function in the shared library, I
> > get an error indicating that the method call is unlinked
> > (ExternalMethod>>unlinkedCall:arguments: and eventually a
> > primLibraryLoad error). The environmental variable is set to point to
> > the correct directory. Running nm -u on the shared library produces
> > the same output as the library in the VW 7.5 version, so I think I
> > have every thing defined.  I can run my application's previous
> > version's image file with the VW 7.5 engine and the environmental
> > variable pointing to the "new" shared library and it works fine. So I
> > think the library is OK. I just can't get VW 7.7.1 engine to see it.
> >
> >
> > Ideas?
> >
> > _______________________________________________
> > vwnc mailing list
> > [hidden email]
> > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

>Thanks for the suggestions so far but, I've tried replacing the
>environmental variable with the actual path with the same results.
>When I step though the stack, the environment variable is being
>interpreted correctly. The name of the shared library is not a symlink.
>
>If I ldd  or ld the shared library the results are the same; ldd on
>vwlinux86gui.so in both directories are the same, different order but
>same libraries are being referenced. If I compare the results of ld
>of the 2 vwlinux86gui.so, the for VW7.7.1 has 2 new references,
>isFiniteDouble  and  loadDoubleFromOop.
>
>
>At 12:03 AM 2/17/2011, Wallen, David wrote:
> >A couple things to try, just in case they yield useful information.
> >Regarding the libraryDirectories attribute, what happens if you ignore
> >the env variable name, and replace it temporarily with the actual path
> >where the shared lives? This should certainly work, and if it doesn't,
> >that's interesting.
> >
> >The other thing to note is that your shared library may depend on
> >another shared, and perhaps that shared can't be found (or loaded),
> >which prevents your intended shared library from loading. Even though it
> >all works in vw7.5, maybe that other shared is somehow accessible to
> >your vw7.5 image (eg., in its image directory).
> >
> >The second one is reaching a bit, but I think the failure to load looks
> >the same whether it's the primary shared, or one of its dependents
> >causing the problem.
> >
> >- Dave
> >
> > > -----Original Message-----
> > > From: [hidden email] [mailto:[hidden email]] On
> >Behalf
> > > Of Jim Harsh
> > > Sent: Wednesday, February 16, 2011 4:36 PM
> > > To: [hidden email]
> > > Subject: [vwnc] VW 7.7.1 on Linux 32
> > >
> > > We have an application that uses an external "C" library. Our
> > > subclass of ExternalInterface is CPOKTestInterface. In the definition
> > > of CPOKTestInterface, the libraryFiles attribute is set to the name
> > > of the shared library, the libraryDirectories is set to an
> > > environmental variable holding the directory path to the shared
> > > library. We've been using this techniques since we started using VW
> > > at about  version 2.5 on DecUnix platforms. Our main development
> > > platform now is Windows, currently XP, 32 bit. We are expanding to
> > > include Linux 32 and 64 bit platforms. This technique worked with the
> > > VW 7.5 engine on all three platforms. It works on Windows and Linux
> > > 64 (Red Hat) with the VW7.7.1 engine but not on the Linux 32 platform
> > > (Debian).
> > >
> > > On Linux 32, when I try to call a function in the shared library, I
> > > get an error indicating that the method call is unlinked
> > > (ExternalMethod>>unlinkedCall:arguments: and eventually a
> > > primLibraryLoad error). The environmental variable is set to point to
> > > the correct directory. Running nm -u on the shared library produces
> > > the same output as the library in the VW 7.5 version, so I think I
> > > have every thing defined.  I can run my application's previous
> > > version's image file with the VW 7.5 engine and the environmental
> > > variable pointing to the "new" shared library and it works fine. So I
> > > think the library is OK. I just can't get VW 7.7.1 engine to see it.
> > >
> > >
> > > Ideas?
> > >
> > > _______________________________________________
> > > vwnc mailing list
> > > [hidden email]
> > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>_______________________________________________
>vwnc mailing list
>[hidden email]
>http://lists.cs.uiuc.edu/mailman/listinfo/vwnc