Lighttpd

If you do not link with libubacktrace.so present, what linker errors do you get? i.e. which symbols are missing?

Have you tried ./configure --with-libunwind=no, or making sure that HAVE_LIBUNWIND is undefined when buffer.c is compiled?

Thanks for your reply @gstrauss.
Did you mean --without-libunwind? I did try without-libunwind it didnt help.
The redacted error that I pasted earlier is without the libubacktrace.so in my build machine's /lib.
If I drop the .so there, then it links good and build is fine.
Strangely, there are no symbols like backtrace or backtrace_* in usage on any of the sources of lighttpd or libpcre. Hence, it is weird that it still looks for libubacktrace.so during linking.

Meanwhile, I will try --with-libunwind=no and see what happens.

Thanks,
Subash

Just an update that --with-libunwind=no does not help and returns the same error as earlier.
It again looks for libubacktrace.so under the build machine's /lib

Thanks,
Subash

Is mod_flv_streaming.so the only lib that fails to link? If you compile with make -k do other things fail to link?

Did you run ldd -r on the openssl libraries to see if they depend on libubacktrace? lighttpd does not have an explicit dependency on libubacktrace so you need to find out why it is needed. If it is not explicitly on the link line, then some other library or link process depends on it.

... From a quick internet search, it might be related to uClibc and cross-compilation. This is definitely not lighttpd-specific, so I think you'll have more luck over in some uClibc forums. From 2012: http://uclibc.10924.n7.nabble.com/PATCH-buildsys-clean-up-libubacktrace-linker-script-handling-td11535.html

From 2016: http://buildroot-busybox.2317881.n4.nabble.com/uclibc-ng-bump-to-1-0-18-td146178.html suggests that there may be a config option for uClibc:

For my purposes I need backtrace support, so I add "UCLIBC_HAS_BACKTRACE=y" into uClibc-ng.config.

This would seem to imply that you might want to compile your uClibc with UCLIBC_HAS_BACKTRACE=n or whatever means "not =y" in uClibc-ng.config

Thanks Glenn.
On make -k, it fails on all mod_*.so builds.
UCLIBC_HAS_BACKTRACE is set to y already in the uClibc release.config file.

The reason why I believe this is lighttpd specific is, I hit this error only when I turn on with-pcre in the lighttpd config/Makefile following the earlier links I pointed to. If I dont turn on with-pcre, everything just builds/links fine. I am trying to pull in pcre so that I can do a regex based URL parsing in lighttpd config.
I have tried the uClibc patch that you pointed out, but it didnt help neither.
May be I will try reaching out that alias as well.

Thanks,
Subash

Please read my response more carefully. I suggested UCLIBC_HAS_BACKTRACE= or =n, not the opposite.
If you're not providing libubacktrace.so.0 on your target systems, why do you think UCLIBC_HAS_BACKTRACE=y is logical?

If lighttpd works without pcre, and the lighttpd build breaks when you add pcre, basic logic suggests that you should look at pcre.
Have you tested build an app with pcre (but not lighttpd), to validate whether or not your problem is introduced with pcre?

Thanks Glenn, appreciate your response.
I also need libubacktrace.so for some other binaries which is packaged as an image, hence I meant =y.
I am currently linking pcre to another app existing in the image just as a test to see if it related to pcre and not lighttpd. I have also removed the with-pcre option to stay on-course on this test.

Thanks,
Subash

It does not look like a pcre issue.
The test of adding -lpcre to another app built/linked just fine.
I verified the linking by running
objdump -p <app_binary> | grep NEEDED
- lists libpcre.so as well.

Thanks,
Subash

What more can I say?

Something has a dependency on libubacktrace.so.0. You need to identify it. lighttpd does not have a direct, explicit dependency on libubacktrace.so.0.
lighttpd does not have any code specific to uclibc. Therefore, this is not a lighttpd issue.

If you enable UCLIBC_HAS_BACKTRACE, then you need to provide libubacktrace.so.0. If you think otherwise, then please validate your assumption on the uclibc forums.

You might be able to link shared libs with unresolved dependencies (depending on linker flags), but when you go to load and run those libs, the program will fail if the dependencies are not present, either at load time, or when used (e.g. dlopen() and friends)

Thanks Glenn for your support.
It is the dependency which I am trying to remove, wherever it seems lingering.
On searching uClibc threads(havent reached out yet), it looks like at some places UBACKTRACE has had its round of static compilation issues/patches and hence it only looks in that "hard-coded" path instead of the regular LD_LIBRARY or -L path.
I will continue digging around and reach out to the uClibc alias.

Thanks,
Subash