On Sun, Jul 9, 2017 at 1:57 AM, Waldek Kozaczuk <[email protected]> wrote:
> Running with -V did not yield any interesting behavior. But when I built > an image with httpserver hoping to be able to list content of the /usr/lib > ditrectory (is there any easier way to verify content of built image apart > from mount it as zfs on linux?) like so: > > ./scripts/build image=httpserver.fg,lighttpd > > I was able to run both successfully to my surprise: > > > [I/244 dhcp]: Configuring eth0: ip 192.168.122.15 subnet mask > 255.255.255.0 gateway 192.168.122.1 MTU 1500 > httpserver: loaded plugin from path: /usr/mgmt/plugins/ > libhttpserver-api-docs.so > httpserver: loaded plugin from path: /usr/mgmt/plugins/ > libhttpserver-api_api.so > could not load libpcre.so.3 > > As you noted, this may be the problem: In external/ we have libpcre.so.1, and this is what you installed in the image. But something - probably lighttpd - was linked with libpcre.so.3, and that is not included in the image. Didn't you get the same message when running with -V and only lighttpd? Can you check with which libpcre you compile lighttpd? Is it the one from external/ or the one from the build machine/? If this is the case, then this seems related to the big issue we have with matching compilers and libraries of various pieces of OSv - see issues 743 and 821. As I noted in issue 743 I think the issue is to stop using *anything* from external/ and eventually remove it, and take everything from the build machine which is used to build both OSv and the application. > > Is it because somehow when httpserver loads it is using a different > mechanism to load so which succeeds vs how same libpcre.so.1 gets loaded by > lighttpd.so? > > Please note 'could not load libpcre.so.3' statement suggesting that > libpcre.so.1 might be dependent on libpcre.so.3? > libpcre.so.1 and libpcre.so.3 are *different* libraries, so if an application was linked with the latter and only the former is available, the linking will fail. However, I'm assuming (I don't know anything about these libraries), that superficially these two libraries are similar. So if lighttpd asked for libpcre.so.3 and accidentally the libpcre.so.1 library got loaded (because httpserver used it), and when the application needed the "pcre_free" symbol it got it from libpcre.so.1, even though the libpcre.so.3 it really wanted wasn't available. Note, by the way, that you *can't* have both versions of the same library loaded at the same time because they'll have the same symbols colliding. You can do this if you run httpserver and lighttpd in different "ELF namespaces" - I think Justin sent a patch to do this through the REST API very recently for the same reason (running two applications with colliding symbols), but we can also easily add an option for the command line parser to run the two applications in different ELF namespace. > > Here is my latest usr.manifest from lighttpd module: > > [manifest] > /usr/lib/&/libpcre.so.1: %(miscbase)s/usr/lib64/& > But how is lighttpd actually linked in the Makefile? Does it explicitly use external/**/libpcre.so.1, or does it use "-lpcre" from the system - and what version is that? Can you please show me the output of "ldd" on lighttpd.so? Nadav. -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
