Error while loading shared libraries: ../lib/libqlibc.so.2: cannot open shared object file: No such file or directory

[ace411]

Hello, there. qlibc is awesome. I am sadly, currently in a pickle: I can't execute the object file created upon successful compilation of a C file containing qhttpclient code. The linker flags -lqlibc -lqlibcext -lssl -lcrypto -pthread work only during compilation, but attempting to run the object file created from the linkage produces the message:

./[file]: error while loading shared libraries: ../lib/libqlibc.so.2: cannot open shared object file: No such file or directory

Any help would be appreciated.

[Fullaxx]

can you provide more information? What OS/distro are you are using? Specifically what instructions did you use to install qlibc?

[wolkykim]

did you install it according to https://github.com/wolkykim/qlibc/blob/master/INSTALL.md if you don't wish to install it and prefer portability then you can build your executables statically using GCC's -static option

[ace411]

can you provide more information? What OS/distro are you are using? Specifically what instructions did you use to install qlibc?

I am running Ubuntu 20.04.5 LTS on WSL 2 on Windows 11.

did you install it according to https://github.com/wolkykim/qlibc/blob/master/INSTALL.md if you don't wish to install it and prefer portability then you can build your executables statically using GCC's -static option

Yes, I did. I typed the following:

$ git clone https://github.com/wolkykim/qlibc.git
$ cd qlibc
$ ./configure --with-openssl
$ make && sudo make install

I am able to, with my current qlibc setup, utilize the container and filesystem artifacts but not the HTTP client.

[wolkykim]

The problem I suspect is that somehow the linker linked them with their relative path rather than absolute path to the library.

I suggest you try this. 1) Rather than using -lqlibc -lqlibcext, you can try /some_path/libqlibcext.a /some_path/libqlibc.a to make it statically included in the executable. (FYI, /usr/local/lib/ is the default path that qlibc get installed with make install command) 2) Or update the LD_LIBRARY_PATH environment variable to include the qlibc library path if you still wish it to be dynamically loaded at the run time.

For instance, if you run make command under examples directory, you will see how examples are built statically with qlibc and qlibcext. Hope this resolves the issue but if it still remains the same, please let me know.

Steve

On Wed, Dec 21, 2022, 12:26 PM Lochemem Bruno Michael < @.***> wrote:

can you provide more information? What OS/distro are you are using? Specifically what instructions did you use to install qlibc?

I am running Ubuntu 20.04.5 LTS on WSL 2 on Windows.

did you install it according to https://github.com/wolkykim/qlibc/blob/master/INSTALL.md if you don't wish to install it and prefer portability then you can build your executables statically using GCC's -static option

• Yes, I did. I typed the following:

$ git clone [https://](https://github.com/wolkykim/qlibc.git $ cd qlibc $ ./configure --with-openssl $ make && sudo make install

I am able to, with my current qlibc setup, utilize the container and filesystem artifacts but not the HTTP client.

— Reply to this email directly, view it on GitHub https://github.com/wolkykim/qlibc/issues/97#issuecomment-1362056924, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUKQMMV5XKVRJVCRRBGEQTWONRZFANCNFSM6AAAAAATC7V3HU . You are receiving this because you commented.Message ID: @.***>

[ace411]

Using the /path/to/libqc.a and /path/to/libqcext.a options - per your prescription - results in the following.

/usr/bin/ld: /usr/local/lib/libqlibcext.a(qhttpclient.o): in function `sendrequest':
/home/chemem/libs/qlibc/src/extensions/qhttpclient.c:1217: undefined reference to `qgrow'
/usr/bin/ld: /usr/local/lib/libqlibcext.a(qhttpclient.o): in function `qhttpclient':
/home/chemem/libs/qlibc/src/extensions/qhttpclient.c:262: undefined reference to `qsocket_get_addr'
collect2: error: ld returned 1 exit status

Adding /usr/local/lib to the LD_LIBRARY_PATHand using the flag -L/usr/local/lib during compilation both produce an error similar to the one I initially reported.

error while loading shared libraries: ../lib/libqlibc.so.2: cannot open shared object file: No such file or directory

Adding the -shared flag like so - cc -shared file /path/to/libqclib.a /path/to/libqclibext.a -lssl -lcrypto -pthread -o file - produces a Segmentation Fault. Analyzing the said fault with Valgrind produces the following trace.

==6139== Memcheck, a memory error detector
==6139== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==6139== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==6139== Command: ./file
==6139== 
==6139== 
==6139== Process terminating with default action of signal 11 (SIGSEGV)
==6139==  Access not within mapped region at address 0x0
==6139==    at 0x1: ???
==6139==    by 0x1FFF0001C6: ???
==6139==  If you believe this happened as a result of a stack
==6139==  overflow in your program's main thread (unlikely but
==6139==  possible), you can try to increase the size of the
==6139==  main thread stack using the --main-stacksize= flag.
==6139==  The main thread stack size used in this run was 8388608.
==6139== 
==6139== HEAP SUMMARY:
==6139==     in use at exit: 0 bytes in 0 blocks
==6139==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==6139== 
==6139== All heap blocks were freed -- no leaks are possible
==6139== 
==6139== For lists of detected and suppressed errors, rerun with: -s
==6139== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Segmentation fault

Am I doing something wrong?

[wolkykim]

Hi,

Do you get the same error when you build the examples? apacheconf example is the one using the ext lib. I will need to reproduce this issue to pinpoint what went south. Can you share your code and Makefile in github or somewhere and let me know how to reproduce it?

On Thu, Dec 22, 2022 at 9:08 AM Lochemem Bruno Michael < @.***> wrote:

Using the /path/to/libqc.a and /path/to/libqcext.a options - per your prescription - results in the following.

/usr/bin/ld: /usr/local/lib/libqlibcext.a(qhttpclient.o): in function sendrequest': /home/chemem/libs/qlibc/src/extensions/qhttpclient.c:1217: undefined reference toqgrow' /usr/bin/ld: /usr/local/lib/libqlibcext.a(qhttpclient.o): in function qhttpclient': /home/chemem/libs/qlibc/src/extensions/qhttpclient.c:262: undefined reference toqsocket_get_addr' collect2: error: ld returned 1 exit status

Adding /usr/local/lib to the LD_LIBRARY_PATHand using the flag -L/usr/local/lib during compilation both produce an error similar to the one I initially reported.

error while loading shared libraries: ../lib/libqlibc.so.2: cannot open shared object file: No such file or directory

Adding the -shared flag like so - cc -shared file /path/to/libqclib.a /path/to/libqclibext.a -lssl -lcrypto -pthread -o file, produces a Segmentation Fault. Analyzing the said fault with Valgrind produces the following trace.

==6139== Memcheck, a memory error detector ==6139== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==6139== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==6139== Command: ./file ==6139== ==6139== ==6139== Process terminating with default action of signal 11 (SIGSEGV) ==6139== Access not within mapped region at address 0x0 ==6139== at 0x1: ??? ==6139== by 0x1FFF0001C6: ??? ==6139== If you believe this happened as a result of a stack ==6139== overflow in your program's main thread (unlikely but ==6139== possible), you can try to increase the size of the ==6139== main thread stack using the --main-stacksize= flag. ==6139== The main thread stack size used in this run was 8388608. ==6139== ==6139== HEAP SUMMARY: ==6139== in use at exit: 0 bytes in 0 blocks ==6139== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==6139== ==6139== All heap blocks were freed -- no leaks are possible ==6139== ==6139== For lists of detected and suppressed errors, rerun with: -s ==6139== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Segmentation fault

Am I doing something wrong?

— Reply to this email directly, view it on GitHub https://github.com/wolkykim/qlibc/issues/97#issuecomment-1363111264, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUKQMJDTNYODWLYW4U7JB3WOSDJBANCNFSM6AAAAAATC7V3HU . You are receiving this because you commented.Message ID: @.***>

[ace411]

Cool. Here's my C file.

#include "stdio.h"
#include "stdlib.h"
#include "qlibc/qlibc.h"
#include "qlibc/qlibcext.h"

int main(int argc, char **argv)
{
  qhttpclient_t *client = qhttpclient("https://jsonplaceholder.typicode.com", 0);
  if (client == NULL)
  {
    return -1;
  }

  qlisttbl_t *reqheaders = qlisttbl(QLISTTBL_UNIQUE | QLISTTBL_CASEINSENSITIVE);
  qlisttbl_putstr(reqheaders, "content-type", "application/json");

  int res;
  size_t res_len;

  void *contents = client->cmd(client, "GET", "/todos/1", NULL, 0, &res,
                               &res_len, reqheaders, NULL);

  if (contents == NULL)
  {
    printf("Failure!\n");
  }
  else
  {
    printf("Contents: %s\n", (char *)contents);
    free(contents);
  }

  return 0;
}

And here's my Makefile.

GCC ?= gcc

FPREFIX = http
LIBS = -lqlibc -lqlibcext -pthread -lssl -lcrypto
CFLAGS = -std=gnu99 -fPIC -shared ${LIBS}

.PHONY: default
default: build

build:
    $(CC) $(FPREFIX).c $(CFLAGS) -o $(FPREFIX)

[wolkykim]

Hi

Looks like the version of GCC you're using is probably having the link order sensitivity. I believe this issue has been resolved with recent gcc but the default install versions on many distributions are still using the old version.

Linking qlibcext before qlibc seems to fix it.

Also I added this update https://github.com/wolkykim/qlibc/pull/98 to enable TLS server name indication extension by default. Some website providers such as Cloudflare which jsonplaceholder.typicode.com is on seem to require server name extension at the handshake phase. It's merged in so please pull and use the latest version of qlibc.

$ make
cc http.c /usr/local/lib/libqlibcext.a /usr/local/lib/libqlibc.a -pthread -lssl -lcrypto -I/usr/local/include/qlibc/ -o http

$ ./http
Contents: {
  "userId": 1,
  "id": 1,
  "title": "delectus aut autem",
  "completed": false
}

$ cat Makefile 
GCC ?= gcc

FPREFIX = http
#LIBS = -lqlibc -lqlibcext -pthread -lssl -lcrypto
LIBS = /usr/local/lib/libqlibcext.a /usr/local/lib/libqlibc.a -pthread -lssl -lcrypto
CFLAGS = ${LIBS} -I/usr/local/include/qlibc/

.PHONY: default
default: build

build:
    $(CC) $(FPREFIX).c $(CFLAGS) -o $(FPREFIX)

[ace411]

Thanks for sharing the information about the TLS server name indication. Updating the Makefile and attempting to compile the C file produced the following error.

cc http.c /usr/local/lib/libqlibcext.a /usr/local/lib/libqlibc.a -pthread -lssl -lcrypto -I/usr/local/include/qlibc/ -o http
In file included from /usr/local/include/qlibc/qlibcext.h:41,
                 from http.c:4:
/usr/local/include/qlibc/extensions/qhttpclient.h:106:24: error: field ‘addr’ has incomplete type
  106 |     struct sockaddr_in addr;
      |                        ^~~~
make: *** [Makefile:11: build] Error 1

Is the problem above gcc related? Should I upgrade my version of gcc as I am currently running v9.4.0?

[wolkykim]

I made this update https://github.com/wolkykim/qlibc/commit/1ef855c828b06fc3fe4eca246b39491af033957d

Can you pull then see if that resolves? Typically, this header is loaded from "qlibc.h" but I made it clear and removed the header dependency

On Sat, Dec 24, 2022 at 12:59 AM Lochemem Bruno Michael < @.***> wrote:

Thanks for sharing the information about the TLS server name indication. I updated the Makefile and got the following error.

cc http.c /usr/local/lib/libqlibcext.a /usr/local/lib/libqlibc.a -pthread -lssl -lcrypto -I/usr/local/include/qlibc/ -o http

In file included from /usr/local/include/qlibc/qlibcext.h:41,

             from http.c:4:

/usr/local/include/qlibc/extensions/qhttpclient.h:106:24: error: field ‘addr’ has incomplete type

106 | struct sockaddr_in addr;

  |                        ^~~~

make: *** [Makefile:11: build] Error 1

Is the problem above gcc related? Should I upgrade my version of gcc?

— Reply to this email directly, view it on GitHub https://github.com/wolkykim/qlibc/issues/97#issuecomment-1364491035, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUKQMPF43T2CMAWV7G3CFTWO23QNANCNFSM6AAAAAATC7V3HU . You are receiving this because you commented.Message ID: @.***>

[ace411]

Hello. Building the new version in the master branch results in the following error.

extensions/qhttpclient.c:493:17: error: dereferencing pointer to incomplete type ‘SSL’ {aka ‘struct ssl_st’}
  493 |         ssl->ssl->tlsext_hostname = client->hostname;
      |                 ^~
make[1]: *** [Makefile:207: extensions/qhttpclient.o] Error 1
make[1]: Leaving directory '/home/chemem/libs/qlibc/src'
make: *** [Makefile:32: all] Error 2

Is the fault an incomplete ssl_st struct type?

[wolkykim]

What version of openssl do you have installed? Output of openssl version -a? Sorry, I've got a family emergency. Will unlikely be able to look into the details for a few days but will get back to you as soon as I can.

On Sat, Dec 24, 2022 at 11:32 AM Lochemem Bruno Michael < @.***> wrote:

Hello. Building the new version in the master branch results in the following error.

extensions/qhttpclient.c:493:17: error: dereferencing pointer to incomplete type ‘SSL’ {aka ‘struct ssl_st’}

493 | ssl->ssl->tlsext_hostname = client->hostname;

  |                 ^~

make[1]: *** [Makefile:207: extensions/qhttpclient.o] Error 1

make[1]: Leaving directory '/home/chemem/libs/qlibc/src'

make: *** [Makefile:32: all] Error 2

Is the fault an incomplete ssl_st struct type?

— Reply to this email directly, view it on GitHub https://github.com/wolkykim/qlibc/issues/97#issuecomment-1364575403, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUKQMOEHNHOOJX5UBEK6DTWO5FUNANCNFSM6AAAAAATC7V3HU . You are receiving this because you commented.Message ID: @.***>

[ace411]

That's fine. We'll pick this up once you've attended to your family, which I hope is all right. Merry Christmas, and thank you for all the help you have provided thus far. Also, I have the 1.1.1f version of openssl installed on my machine.