[Glass] GemBuilder for C compilation on 3.6.1
Iwan Vosloo
iwan at reahl.org
Mon Jun 21 23:11:38 PDT 2021
Hi Norm,
No, we're not trying to statically link with libgcits-3.6.1-64.so, we
want to link to it dynamically, but not by using the GciTsLoad
mechanism. Or at least that's how I understand it.
The context is that we have code in Cython which calls your Gci code.
From Cython code, C++ code is generated which, when compiled, can be
imported in Python and called from there.
We were able to do this before on 3.4.1 by specifying
libgcits-3.6.1-64.so as a library directly, but I always assumed this
means dynamic.
My initial test program, when not using GciTsLoad, and with
-L${GEMSTONE}/lib -lgcits-3.6.1-64 added to the linking stage was my
simplification of what our Cython code does. This is normal dynamic
linkink, not so? This also segfaults.
If I use GciTsLoad in the test program, as you suggested then it works.
With this in mind I have played with the Cython code a bit now, and have
been able to get the calls to GciTsLoad to succeed, but still when it
gets to executing a call like GciTsEncrypt inside the loaded library it
always segfaults.
Perhaps it is the same problem, and my earlier reproduction of the issue
is the easiest to hunt down?
Thank you
Iwan
On 2021/06/21 19:51, Norm Green via Glass wrote:
> My bad, I just realized you weren't trying to statically link the gem
> executable, rather you were trying to statically link the GCI thread
> safe library. We don't currently support that either but it could be
> supported without too much trouble. Would still like to know why you
> need to statically link vs loading the shared library with GciTsLoad() ?
>
> Norm
>
>
> On 6/21/2021 9:22 AM, Norm Green wrote:
>> So you were trying to statically link you application with
>> libgcits-3.6.1-64.so ? Statically linking a gem executable is not
>> supported. We would need to provide you libgcits-3.6.1-64.a. Can you
>> please explain why you need to do this?
>>
>> If you were trying to dynamically link then the solution I presented
>> should suffice.
>>
>> Norm
>>
>>
>>
>>
>> On 6/20/2021 11:52 PM, Iwan Vosloo via Glass wrote:
>>> Thank you Norm,
>>>
>>> Yes, that works, and I saw that is what's recommended in the manual.
>>> The problem is this is a simplified example of a larger project where
>>> I have other constraints. One of these in the past was that we had to
>>> link libgcits explicitly and could not make use of GciTsLoad.
>>>
>>> Either way - I can use this to try and see if I can get GciTsLoad to
>>> work in our environment. I can't remember why we had that constraint
>>> before.
>>>
>>> However, surely linking libgcits directly should also be possible?
>>>
>>> The only thing I see changed in the header files is that these
>>> functions have GCI_WEAK appended now, which was not there before. It
>>> is defined on Linux as __attribute__((weak))
>>>
>>> Thanks
>>> Iwan
>>>
>>>
>>> On 2021/06/21 01:06, Norm Green via Glass wrote:
>>>> Iwan,
>>>>
>>>> I was able to get it work with the following changes based on your
>>>> code:
>>>>
>>>>
>>>>
>>>> // test.c
>>>>
>>>> #include <stdio.h>
>>>> #include <gcits.hf>
>>>>
>>>> int main() {
>>>> // load the GciTS library first
>>>> char msg[256];
>>>> const char* path = NULL;
>>>> if (! GciTsLoad(path, msg, sizeof(msg))) {
>>>> printf("ERROR: GciTsLoad failed %s\n", msg);
>>>> exit(1);
>>>> }
>>>>
>>>> const char *unencrypted_password = "abcde";
>>>> char *out_buff;
>>>> char *encrypted_password;
>>>> int encrypted_char;
>>>> unsigned int out_buff_size = 1000;
>>>> out_buff = (char *)malloc(out_buff_size * sizeof(char));
>>>> GciTsEncrypt(unencrypted_password, out_buff, out_buff_size);
>>>> free(out_buff);
>>>> return 0;
>>>> }
>>>>
>>>> -------------------------------------------
>>>> # test.mak - link with gcirtlobj.o instead of libgcits. GciTsLoad()
>>>> will load the shared lib.
>>>>
>>>>
>>>> COMPILE_FLAGS=-fmessage-length=0 -fcheck-new -O3 -ggdb -m64 -pipe \
>>>> -D_REENTRANT -D_GNU_SOURCE -pthread -fPIC \
>>>> -fno-strict-aliasing -fno-exceptions -x c++
>>>>
>>>> LINK_FLAGS=-m64 -Wl,-Bdynamic,--no-as-needed -lpthread
>>>> -Wl,--as-needed \
>>>> -lcrypt -ldl -lc -lm -lrt -Wl,-traditional -Wl,-z,lazy
>>>>
>>>> all:
>>>> g++ -I${GEMSTONE}/include ${COMPILE_FLAGS} -c test.c -o test.o
>>>> g++ ${GEMSTONE}/lib/gcirtlobj.o ${LINK_FLAGS} test.o -o test
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 6/20/2021 1:39 AM, Iwan Vosloo via Glass wrote:
>>>>> Hi all,
>>>>>
>>>>> I am trying to compile C code that calls GemBuilder for C functions.
>>>>> I take inspiration from
>>>>> https://downloads.gemtalksystems.com/docs/GemStone64/3.6.x/GS64-GemBuilderforC-3.6.pdf
>>>>> sections 5.2 and 5.3.
>>>>>
>>>>> I am doing this on Ubuntu 20.04, using g++ 9.3.0 all of which are
>>>>> supported according to the above doc.
>>>>>
>>>>> I also have installed GemStone64Bit3.6.1-x86_64.Linux
>>>>>
>>>>> I have a simplified test program that just calls a simple function
>>>>> from libgcits. I can compile and link, but when I run the resultant
>>>>> program it segfaults when I callthe Gci function. I have to confess
>>>>> that I haven't touched C in 20 years, so I am probably doing stupid
>>>>> things. (I had this working with GemStone 3.4.1)
>>>>>
>>>>> Here is my program (test.c):
>>>>>
>>>>> #include <stdio.h>
>>>>> #include <gcits.hf>
>>>>>
>>>>> int main() {
>>>>> const char *unencrypted_password = "abcde";
>>>>> char *out_buff;
>>>>> char *encrypted_password;
>>>>> int encrypted_char;
>>>>> unsigned int out_buff_size = 1000;
>>>>> out_buff = (char *)malloc(out_buff_size * sizeof(char));
>>>>> GciTsEncrypt(unencrypted_password, out_buff, out_buff_size);
>>>>> free(out_buff);
>>>>> return 0;
>>>>> }
>>>>>
>>>>> I build it using this makefile:
>>>>>
>>>>> COMPILE_FLAGS=-fmessage-length=0 -fcheck-new -O3 -ggdb -m64 -pipe \
>>>>> -D_REENTRANT -D_GNU_SOURCE -pthread -fPIC \
>>>>> -fno-strict-aliasing -fno-exceptions -x c++
>>>>>
>>>>> LINK_FLAGS=-m64 -Wl,-Bdynamic,--no-as-needed -lpthread
>>>>> -Wl,--as-needed \
>>>>> -lcrypt -ldl -lc -lm -lrt -Wl,-traditional -Wl,-z,lazy
>>>>>
>>>>> all:
>>>>> g++ -I${GEMSTONE}/include ${COMPILE_FLAGS} -c test.c -o test.o
>>>>> g++ -L${GEMSTONE}/lib -lgcits-3.6.1-64 ${LINK_FLAGS} test.o -o
>>>>> test
>>>>>
>>>>>
>>>>> The options above are taken from 5.3 of the doc, except that I link
>>>>> gcits-3.6.1-64 library directly instead of using the run time
>>>>> loading as is explained earlier in the doc.
>>>>>
>>>>> What am I missing here?
>>>>>
>>>>> Regards
>>>>> Iwan
>>>>>
>>>>
>>>> _______________________________________________
>>>> Glass mailing list
>>>> Glass at lists.gemtalksystems.com
>>>> https://lists.gemtalksystems.com/mailman/listinfo/glass
>>>
>>>
>>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> https://lists.gemtalksystems.com/mailman/listinfo/glass
--
More information about the Glass
mailing list