wolkykim/qlibc

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

Closed this issue · 13 comments

ace411 commented

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 commented

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

wolkykim commented

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 commented

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 commented
ace411 commented

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 commented
ace411 commented

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 commented

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 #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 commented

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 commented
ace411 commented

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 commented
ace411 commented

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.