* Problem with dlsym against libicu
@ 2016-01-23 14:35 Sam Habiel
2016-01-23 19:09 ` Ken Brown
0 siblings, 1 reply; 2+ messages in thread
From: Sam Habiel @ 2016-01-23 14:35 UTC (permalink / raw)
To: cygwin
Hello all.
I am porting GT.M
(https://www.fisglobal.com/Solutions/Services/Database-Engine) to run
on Cygwin x86. My changes are here:
https://github.com/shabiel/fis-gtm/. GT.M is used in healthcare and
banking; I happen to work in the former field.
The problem I am having is that GT.M opens libicuio via dlopen, and
then loads the function pointers into a data structure via function
name using dlsym. For the curious, the code is in gtm_icu_init() in
gtc_icu.c
I took me a while, but I eventually figured out that dlls that are
opened via dlopen need to be in the PATH in Cygwin. I saw this in an
earlier Cygwin mailing list message.
However, no matter what I do, I can't seem to get a non-null reference
to a named symbol in libicuio via dlsym. Here's what I tried:
0. nm shows the symbols in the file I want to open; strace shows me
opening it (it's /usr/lib/cygicuio56.dll).
1. Compiled libicu from source with a flag for Cygwin:
http://site.icu-project.org/
2. Used underscores in front of the symbol
3. Tried creating an import library using the instructions at
https://cygwin.com/cygwin-ug-net/dll.html#dll-build at the bottom and
then add the archive to the gcc compile command as a source file.
(These instructions need to be improved! I had no idea what to do with
a .a file after I got it).
Here's a test program that I have written. Note that dlsym returns the
obscure error message "no such process", which doesn't make any sense
to me, as I am not looking for a "process" but a symbol.
sam@horus ~/fis-gtm-cygwin
$ cat test.c
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>
int main (int arg, char **argv)
{
void *ptr = dlopen("cygicuio.dll", RTLD_LAZY);
if (ptr != NULL)
{
printf("%p\n",ptr);
}
else
{
printf("%s",dlerror());
exit(1);
}
void *ptr2 = dlsym(ptr,"uset_open");
if (ptr2 != NULL)
{
printf("%p\n",ptr2);
}
else
{
printf("%s",dlerror());
exit(1);
}
return 0;
}
sam@horus ~/fis-gtm-cygwin
$ gcc -Wall -otest.o test.c
sam@horus ~/fis-gtm-cygwin
$ ./test.o
No such file or directory
sam@horus ~/fis-gtm-cygwin
$ PATH=/usr/lib:/usr/bin:/usr/local/bin:. ./test.o
0x6aa40000
No such process
sam@horus ~/fis-gtm-cygwin
--
Sam Habiel, Pharm.D.
VISTA Expertise Network
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Problem with dlsym against libicu
2016-01-23 14:35 Problem with dlsym against libicu Sam Habiel
@ 2016-01-23 19:09 ` Ken Brown
0 siblings, 0 replies; 2+ messages in thread
From: Ken Brown @ 2016-01-23 19:09 UTC (permalink / raw)
To: cygwin
On 1/22/2016 10:49 PM, Sam Habiel wrote:
> Hello all.
>
> I am porting GT.M
> (https://www.fisglobal.com/Solutions/Services/Database-Engine) to run
> on Cygwin x86. My changes are here:
> https://github.com/shabiel/fis-gtm/. GT.M is used in healthcare and
> banking; I happen to work in the former field.
>
> The problem I am having is that GT.M opens libicuio via dlopen, and
> then loads the function pointers into a data structure via function
> name using dlsym. For the curious, the code is in gtm_icu_init() in
> gtc_icu.c
>
> I took me a while, but I eventually figured out that dlls that are
> opened via dlopen need to be in the PATH in Cygwin. I saw this in an
> earlier Cygwin mailing list message.
>
> However, no matter what I do, I can't seem to get a non-null reference
> to a named symbol in libicuio via dlsym. Here's what I tried:
>
> 0. nm shows the symbols in the file I want to open; strace shows me
> opening it (it's /usr/lib/cygicuio56.dll).
> 1. Compiled libicu from source with a flag for Cygwin:
> http://site.icu-project.org/
> 2. Used underscores in front of the symbol
> 3. Tried creating an import library using the instructions at
> https://cygwin.com/cygwin-ug-net/dll.html#dll-build at the bottom and
> then add the archive to the gcc compile command as a source file.
> (These instructions need to be improved! I had no idea what to do with
> a .a file after I got it).
>
> Here's a test program that I have written. Note that dlsym returns the
> obscure error message "no such process", which doesn't make any sense
> to me, as I am not looking for a "process" but a symbol.
>
> sam@horus ~/fis-gtm-cygwin
> $ cat test.c
> #include <dlfcn.h>
> #include <stdio.h>
> #include <stdlib.h>
>
>
> int main (int arg, char **argv)
> {
> void *ptr = dlopen("cygicuio.dll", RTLD_LAZY);
> if (ptr != NULL)
> {
> printf("%p\n",ptr);
> }
> else
> {
> printf("%s",dlerror());
> exit(1);
> }
>
> void *ptr2 = dlsym(ptr,"uset_open");
>
> if (ptr2 != NULL)
> {
> printf("%p\n",ptr2);
> }
> else
> {
> printf("%s",dlerror());
> exit(1);
> }
>
> return 0;
> }
I can't answer your questions, but I have some comments and questions.
First, there's no /usr/lib/cygicuio56.dll in the Cygwin icu
distribution. The DLL is /usr/bin/cygicuio56.dll, with the
corresponding import library /usr/lib/libicuio56.dll.a (provided by the
libicu-devel-56.1 package). And there's also a symlink
/usr/lib/libicuio.dll.a -> libicuio56.dll.a.
Next, can you show the nm command by which you found uset_open? I
couldn't find it. I tried
$ nm /usr/lib/libicuio56.dll.a | grep uset_open
and got nothing. On the other hand:
$ strings /usr/bin/cygicuio56.dll | grep uset_open
uset_open_56
Could the problem be that uset_open (or uset_open_56) isn't exported?
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-01-23 15:21 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-23 14:35 Problem with dlsym against libicu Sam Habiel
2016-01-23 19:09 ` Ken Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).