How can I tell MacPorts that I already have a certain library installed?
For example, I built libcurl from scratch to get http2 protocol with nghttp2, openssl and zlib. I installed them to /opt/local -- same location as all MacPort libs on my system. However, Macports doesn't recognize that they are installed already.
How can I tell MacPorts that these are already installed as well as their versions? Why? Because I'm trying to do:
port install py35-pip but it lists that libz and openssl are not installed.
MacPorts does not support this, for multiple reasons:
You should not manually modify files in /opt/local that would usually be managed by MacPorts. MacPorts keeps certain metadata (like the required dependencies) about installed files, which no longer works when you manually install files in /opt/local.
MacPorts does not know which configuration you used to build the binary that you manually installed in /opt/local. It could be a version that no longer works with a certain dependency, it could be built against a different C++ standard library in case of C++ code, or it could be incompatible for a number of other reasons. Because MacPorts wants to reduce the support burden for requests from people that have modified some of their ports like that, it is not a support feature of MacPorts to do that.
However, MacPorts already supports installing curl with nghttp2 support. See the output of port variants curl:
curl has the variants:
ares: Support resolving names asynchronously
darwinssl: Allow secure connections using GNU TLS
* conflicts with gnutls ssl wolfssl
gnutls: Allow secure connections using GNU TLS
* conflicts with darwinssl ssl wolfssl
gss: Support the Generic Security Service API
http2: Support HTTP/2 with nghttp2
idn: Enable support for internationalized domain names (IDN)
metalink: Support Metalink XML download description files
openldap: Support performing Lightweight Directory Access Protocol queries with OpenLDAP
sftp_scp: Support SFTP/SCP connections via libssh2
spnego: Enable SPNEGO authentication support
[+]ssl: Allow secure connections using OpenSSL
* conflicts with darwinssl gnutls wolfssl
universal: Build for multiple architectures
wolfssl: Allow secure connections using wolfSSL, formerly CyaSSL
* conflicts with darwinssl gnutls ssl
So in this case, you can just install curl +http2, either using sudo port install curl +http2 (if you didn't have it installed already) or using sudo port upgrade --enforce-variants curl +http2 (if you had it installed already) to achieve the same thing.
See also https://trac.macports.org/wiki/FAQ#usrlocal for /usr/local and MacPorts in general.
Related
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.
I need to download a file from an ftp server and I found this example using libcurl ftpget.c. It works great in Linux with gcc, but I want my program to work in Windows as well. I noticed there's a port in vcpkg so I installed it with vcpkg install curl[*]:x64-windows without any error. However, the problem is that this version of libcurl doesn't seem to support ftp as it just says * Protocol "ftp" not supported or disabled in libcurl and fails. If I use http or even https it works just fine. I don't know if ftp is simply not supported or if I need to enable it somewhere. I opened an issue on vcpkg github page but didn't get any reply.
vcpkg install curl[non-http]:x64-windows solved my problem thanks to myd7349.
I guess I did vcpkg install curl:x64-windows instead previously and by default USE_HTTP_ONLY is set for some reason so other protocols are all disabled.
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'm trying compile pgbouncer to use in a PostgreSQL server running in windows server 2008. However I simply can't compile the dll, and the same error appears in linux (ubuntu) and in windows:
checking for libevent... configure: error: not found: cannot proceed
I'm following this howto. I've compiled the libevent in windows using mingw and copied the dlls generated to System32, SysWOW64 and even in own pgbouncer directory. What am I doing wrong?
configure is checking whether it will be possible for the package build
to link libevent. For that it needs see that libevent development
dependencies are satisfied. It checks not only that libevent itself can be found
for linkage but that the header <event.h> (exactly like that) can be
found for compilation.
For configure to succeed you must make sure that:-
event.h from your libevent package will be found in the default or
configured include-search paths of the compiler.
The libevent binary will be found in the default or configured library-search
paths of the linker.
Near the top of the HowTo that you
have referred to you will see that configure accepts a parameter
--with-libevent=libevent-prefix that can make this easy. ./configure --help
says:
--with-libevent=prefix Specify where libevent is installed
For your ubuntu system the short answer would be: install libevent-dev from
the package manager. In Ubuntu you could also install pgbouncer from
the package manager, but perhaps you want the latest version.
You need to install libevent-devel, that supplies 2 event.h files:
# find / -name event.h 2>/dev/null
/usr/include/event.h
/usr/include/event2/event.h
To install run:
yum install libevent-devel.x86_64
If you want to compile pgBouncer for Windows, follow my instructions under https://sepppenner.github.io/PgBouncerWinBinaries/ or https://github.com/SeppPenner/PgBouncerWinBinaries.
I am trying to get memcached running on Windows. I have downloaded memcached stable latest and compiled it using Mingw under Windows 7. Configure failed with error,
checking for libevent directory... configure: error: libevent is
required. You can get it from http://www.monkey.org/~provos/libevent/
If it's already installed, specify its path using --with-libevent=/dir/
Then I downloaded libevent and compiled it. This produced 3 DLLs, libeventcore, libevent-extra and libevent-2.0.5.
I ran configure on memcached again with the option --with-libevent. But for some reason, it fails again with the same error. I have no clue on why it is failing. Can anyone help me to resolve this issue? Or is there a better way to get memcached running on Windows? I have seen lot of pre-built binaries for Windows. But all of them uses old versions of memcached. And AFAIK, Windows is officially supported by memcached in the newer versions.
I am using Windows7 64bit version with MinGW.
After you run make in libevent dir you get the files ready, but to make full use of it, they must be installed. So make install step is needed. If you configured it with a prefix, it will land in the directory of your choice. Otherwise it is /usr/local.
So maybe it's enough to run make install in libevent dir and run configure from memcache without parameters.
If you still have problems passing the configure stage, look at config.log. It shows the source file and the gcc command on which it failed.
Unfortunately successful configure is not everything. Later it fails on inclusion of sys/socket.h, netinet/in.h and netdb.h and perhaps also -pthread gcc parameter. I'm afraid it won't compile on mingw. At least not without a serious porting effort.
As I know, Never had an official Memcached port for Windows (Yes, there were few individual efforts. Last knowing porting effort can find on version 1.2.6 here) Best known Implementation for Memcached for windows on Couchbase with Memcached Bucket.
Late to the party I realize but the answer is to use:
$ export LIBS=-lws2_32
which will place $LIBS at the end of compile calls so that it is linked to libws2_32.a or winsocks2, but this probably means that your did not configure your build correctly and you will subsequent errors such as #include <sys/socket.h> header not found, etc.
see mingw-linker-error-winsock