Curl lists openSSL as an external dependency on https://curl.se/docs/libs.html.
However, if I do otool -L $(which curl) (macOS 12.5) I get the following output:
/usr/bin/curl:
/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.120.1)
No openSSL. Is this because it is only needed to compile/build curl but is not needed as an external library at runtime?
Will curl still work if I delete openSSL?
If your curl knows how to speak HTTPS or any other protocol that needs TLS, then your curl depends on a TLS library.
OpenSSL is one such a library, but curl currently supports 13 different TLS libraries that it can be built to use.
If your curl speaks a TLS protocol, it depends on one of those supported libraries. On macOS, Apple seems to have favored libressl lately but in the past they also made builds using Secure Transport directly.
The curl -V output shows which TLS library it uses in the first line, but it might take a little experience to fully understand it. TLS libraries mentioned within parentheses there are optionally enabled by the application at start.
The libraries showed in the otool output are dynamically linked at run-time. It means they need to be present and loadable when you invoke curl so that the run-time linker can load them and execute curl fine.
If you build curl yourself or download someone else's build, you can also link it statically and then all the libraries can be built into a single huge binary blob, but that is not how curl is usually built and shipped in operating systems like macOS and Linux distributions.
Related
I compile my Linux app on Debian Wheezy. It runs and works on all Linux distros.
Recently, I added a dependency of libcurl (needed to make some https requests), now my app doesn't work on Linux distros which don't have libssl.so.1.0.0 present like fedora ships OpenSSL version 1.1.
I just needed a libcurl dependency and got caught in this openssl version issue. My app doesn't care which OpenSSL lib is installed, it just needs libcurl to run, so is this possible to add libcurl.so as a dependency only and installed libcurl will automatically use the ssl lib it was compiled for.
Your app does not care about which OpenSSL is installed - but LIBCURL does ;-)
So, in order to use libcurl as you are expecting, I guess you will have to use libcurl as a static library, compiled with SSL using OpenSSL - which should also be a static library. Optionally, you could use libtool to merge them into a single library.
How to build it? => https://curl.haxx.se/docs/install.html
I want to cross-build partprobe (e.g. parted-3.1 from [here] ) for an ARMv7-controller but keep getting error messages concerning libuuid and uuid_generate.
Actually I only need partprobe which may not even rely on that uuid_generate function, but I don't see any options in the configure script to disable any features.
I've successfully cross-built software before using the BPS as well as using the ARM toolchain provided by my distribution (Mint 17).
Here's what I've tried so far:
1) Using the manufacturer's BSP
I have a board support package that provides libraries and headers as well as a toolchain:
/path/to/bsp/_rootfs/lib/libuuid.so.1
/path/to/bsp/_rootfs/lib/libuuid.so.1.3.0
/path/to/bsp/board-support/linux-3.2.0-psp04.06.00.11/include/linux/uuid.h
/path/to/bsp/linux-devkit/am3352/bin/
When I invoke
./configure \
--libdir=/path/to/bsp/_rootfs/lib/ \
--includedir=/path/to/bsp/board-support/linux-3.2.0-psp04.06.00.11/include/ \
--bindir=/path/to/bsp/linux-devkit/am3352/bin/ \
--with-sysroot=/path/to/bsp/_rootfs \
--host=arm-linux-gnueabihf
I get the following error
checking for uuid_generate in -luuid... no
configure: error: GNU Parted requires libuuid - a part of the util-linux-ng package (but
usually distributed separately in libuuid-devel, uuid-dev or similar)
This can probably be found on your distribution's CD or FTP site or at:
http://userweb.kernel.org/~kzak/util-linux-ng/
Note: originally, libuuid was part of the e2fsprogs package. Later, it
moved to util-linux-ng-2.16, and that package is now the preferred source.
The uuid.h and libraries are available, so I thought the configure script should not complain, but the error seems to be misleading. The header uuid.h is available but does not contain a uuid_generate function declaration, while the library contains such a function (checked with nm -D).
I'm not sure what to do with that...does the BSP contain incompatible version of the header and the library?
However the busybox binary contains wget which seems to use uuid_generate...at some point it must have worked.
Replacing the original uuid.h with a uuid.h.in from the /path/to/bsp/docs/am3352/licenses/e2fsprogs/ (which contains uuid_generate) still results in the same error.
2) Using the Linux distro's ARM-environment
I also tried using the ARM-toolchain provided by my Linux distribution (packages gcc-arm-linux-gnueabihf, libuuid1:armhf)
aptitude install uuid-dev:armhf
shows conflicts with the x86 package of uuid-dev, but there are already available:
/usr/arm-linux-gnueabi/include/linux/uuid.h
/usr/arm-linux-gnueabihf/include/linux/uuid.h
/lib/arm-linux-gnueabihf/libuuid.so.1
/lib/arm-linux-gnueabihf/libuuid.so.1.3.0
BTW: None of those two header files includes a string uuid_generate, while the libraries do.
Invoking
./configure host=arm-linux-gnueabihf
runs without errors, but creates a Makefile that lacks any info on the cross-build environment.
BTW: Invoking make anyway exits with error; trying the same with the current source code from git://git.savannah.gnu.org/parted.git configures and builds successfully, but no magic involved: the result are libraries/binaries for x86 and not for ARM.
Right now I'm at my wits' end - so my question is:
Can someone see the problem(s) I'm missing?
So I've upgraded to a newer version of Linux kernel using Yocto. The new kernel version is for 4.1.15 and runs on an iMX6 chip. I've also included openssh-server, tools-sdk, and tools-debug for development recipes. The problem is that when I connect to build I get the following error:
loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof
(_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))'
failed
Now if I type into the command prompt sh -c "LANG=en_US" I get the same error as above. If I type in sh -c "LANG=/usr/lib/locale/en_US" then I do not get an error. When I type locale everything is listed as POSIX and when I type locale -a I get:
C
POSIX
en_GB
en_US
The last two are stored under /usr/lib/locale. My version of gcc is 5.2 and my glibc is v2.22. I've looked all over the internet for other solutions but they are either for Ubuntu where the package manager comes in handy or it's some really specific fix like editing a file that I don't have in my Yocto build.
Edit:
The machine is for a SMARC-FiMX6 SoM and the instructions are here. I'm not sure what branch of Yocto is being pulled down.
After troubleshooting the problem is from the glibc library. A patch, #114739, is on the openembedded website which details what to do to fix this issue. Just patch the file, rebuild, and the issue is fixed. See here for details, the patch is at the bottom of the page.
Unfortunately apple has not included header files for libicucore on OSX. Is there any way I can nevertheless use this library? I only need some simple functionality and ICU is too big to bundle with my app. It looks like ICU version 53.1.0 which is fairly recent:
jeroen$ otool -L /usr/lib/libicucore.dylib
libicucore.dylib:
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 53.1.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
What complicates things is that I have a hard time finding out what is included with the core target of ICU. I can use nm to manually check if a particular symbol is present in the library:
jeroen$ nm /usr/lib/libicucore.dylib | grep ToUpper
00000000000b74c9 T _u_strToUpper
000000000006ff70 T _ucasemap_utf8ToUpper
Now I can manually grab the headers for u_strToUpper from the 53.1.0 release of ICU, but that is a lot of work. Is there a better way to find or generate the headers for ICU core 53.1.0 on OSX?
You can download header files from Apple's or ICU's official websites and link against the system's libicucore library. But you can't upload a product to App Store or Mac App Store. It will be immediately rejected as one that uses private API. iTunes Connect has an automatic script that detects such references after you upload a new binary.
It looks like my best bet is grabbing the headers from the apple website. This repository also includes the makefile for libicucore.dylib which uses --with-data-packaging=archive to put the ICU data tables in a standalone file /usr/share/icu/icudt51l.dat.
This is kind of an ugly one, but I am stuck so here it goes:
I am writing a dynamic library (henceforth 'mylib.dylib') that uses opencv (highgui and other parts) and is ultimately loaded by ffmpeg (libavfilter). The library compiles just fine. But when I try to dlopen() the dylib from within ffmpeg, I get the following error:
mylib.dylib: dlopen(mylib.dylib, 2): Library not loaded: /usr/local/lib/libpng15.15.dylib
Referenced from: /usr/local/lib/libopencv_highgui.2.3.dylib
Reason: Incompatible library version: libopencv_highgui.2.3.dylib requires version 17.0.0 or later, but libpng15.15.dylib provides version 16.0.0
However, when I run otool -L /usr/local/lib/libpng15.15.dylib I get the following:
/usr/local/lib/libpng15.15.dylib:
/usr/local/lib/libpng15.15.dylib (compatibility version 20.0.0, current version 20.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0)
Last time I checked, 20.0.0 is later than 17.0.0, which is what highgui said it requires.
I thought maybe it was an architecture problem (I am on a Mac running Lion, so I've encountered a lot of problems with i386/x86_64), but running 'file' on all of the libraries revealed that everything (highgui, libpng, mylib) is Mach-O 64-bit dynamically linked shared library x86_64
I thought perhaps there was some other version of libpng hiding on my system somewhere, but the dlopen error specifically points to /usr/local/lib/libpng15.15.dylib
There is obviously something that I am missing here -- admittedly I am no expert on how these dynamic libraries link. So if I forgot to include some pertinent info, please excuse me.
UPDATE
I forgot to mention -- the lib works fine when I run ffmpeg through XCode (no dlopen error) which leads me to believe that it might have something to do with a environment variable that XCode is setting that I am not.
Thanks!
SOLUTION
1. Don't be dumb
I was using MAMP and since I was calling ffmpeg through a php script, it was using its own set of dylibs, which (surprise surprise) included libpng 16.0.0
I had something similar recently after I uninstalled all my MacPorts and installed updated versions. The problem was the version of libpng (1.2 vs 1.4 vs 1.5), not just the compatibility version. I had built OpenCV against libpng 1.4 (which is libpng14). I thought I could just use install_name_tool to make it look at libpng 1.5 (libpng15) instead but that didn't work. I ended up rebuilding OpenCV against the current versions of the library. That worked fine (after I remembered sudo cmake install).
(Some version numbers above might be incorrect but the gist is accurate.)
So either you don't have the version of libpng you originally had when you built OpenCV or it built against a libpng other than the one in /usr/local/lib (like maybe the one in /opt/local/lib). If that's the case you'll need to make sure you're building against the version you want to use. How to do that depends on your build method (MacPorts or cmake). I use cmake for OpenCV and MacPorts for other libraries which is why the two got out of sync on my system.
Just for those who need the code:
cd /Applications/MAMP/Library/lib
mv libpng15.15.dylib libpng15.15.dylib_old
ln -s /usr/X11/lib/libpng15.15.dylib .