With the help of question #197444, I have managed to build cURL & libcurl from source on Windows from within the Visual Studio 2010 IDE, OpenSSL 1.0.0, and zlib 1.2.5. The problem I see is that at the moment, if I run the resulting curl.exe with the argument -V, then the version that it report is
curl 7.20.1 (i386-pc-win32) libcurl/7.20.1 OpenSSL/0.9.8d zlib/1.2.3
Protocols: dict file ftp ftps http https imap imaps ldap pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS Largefile NTLM SSL libz
Note the versions reported for both OpenSSL & zlib doesn't match if what I actually used. Any idea on how to fix this?
p.s. Is there a clear list of optional components that can be compiled into libcurl and what options/preprocessor directive to use? (e.g. SSPI, libidn, ...?)
I took a quick peek at the curl source code and it is getting those version numbers dynamically from the DLLs, not from any static sources. So those are the versions of the libraries that are actually loaded into the curl process, not the versions of the libraries that were used to build the curl source. You probably have older versions of those libraries on your system that are getting loaded by the curl process.
I build cURL and libcurl from command line with this batch file
#echo off
rem assumes OpenSSL at ../../openssl-1.0.0a
rem assumes zlib at ./../zlib-1.2.5 and built with static runtime libraries (/MT)
echo "Add '#define HAVE_LDAP_SSL 1' to lib\config-win32.h"
notepad lib\config-win32.h
pause
cd lib
nmake -f Makefile.vc9 clean
nmake -f Makefile.vc9 OPENSSL_PATH=../../openssl-1.0.0a ZLIB_PATH=../../zlib-1.2.5 RTLIBCFG=static CFG=release-ssl-zlib
cd ..
cd src
nmake -f Makefile.vc9 clean
nmake -f Makefile.vc9 OPENSSL_PATH=../../openssl-1.0.0a ZLIB_PATH=../../zlib-1.2.5 RTLIBCFG=static CFG=release-ssl-zlib
And this is what I get as version
curl 7.21.0 (i386-pc-win32) libcurl/7.21.0 OpenSSL/1.0.0a zlib/1.2.5
Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS Largefile NTLM SSL libz
Related
I'm running macOS Catalina 10.15.7 and I need to install Oracle Instant Client to run run a Perl script that connects to a DB.
1. Installing Oracle Instant Client
I downloaded the packages I needed:
Basic Light Package (DMG)
SDK Package (DMG)
ODBC Package (DMG)
From Instant Client 19.8 and followed the installation instructions without any issues (just copying and pasting)
The files are extracted in /Users/username/Downloads/instantclient_19_8
2. Setting ORACLE_HOME
Next, I did set ORACLE_HOME to /Users/username/Downloads/instantclient_19_8
export ORACLE_HOME=/Users/username/Downloads/instantclient_19_8
3. Installing DBD::Oracle
When I tried to install DBD::Oracle I got the following error:
$ cpanm DBD::Oracle
--> Working on DBD::Oracle
Fetching http://www.cpan.org/authors/id/M/MJ/MJEVANS/DBD-Oracle-1.80.tar.gz ... OK
Configuring DBD-Oracle-1.80 ... N/A
! Configure failed for DBD-Oracle-1.80. See /Users/username/.cpanm/work/1608142485.48272/build.log for details.
The log file's content:
$ cat /Users/username/.cpanm/work/1608142485.48272/build.log
cpanm (App::cpanminus) 1.7044 on perl 5.032000 built for darwin-thread-multi-2level
Work directory is /Users/username/.cpanm/work/1608142485.48272
You have make /usr/bin/make
You have LWP 6.47
You have /usr/bin/tar: bsdtar 3.3.2 - libarchive 3.3.2 zlib/1.2.11 liblzma/5.0.5 bz2lib/1.0.6
You have /usr/bin/unzip
Searching DBD::Oracle () on cpanmetadb ...
--> Working on DBD::Oracle
Fetching http://www.cpan.org/authors/id/M/MJ/MJEVANS/DBD-Oracle-1.80.tar.gz
-> OK
Unpacking DBD-Oracle-1.80.tar.gz
Entering DBD-Oracle-1.80
Checking configure dependencies from META.json
Checking if you have Config 0 ... Yes (5.032000)
Checking if you have Encode 0 ... Yes (3.06)
Checking if you have Math::BigInt 0 ... Yes (1.999818)
Checking if you have Devel::Peek 0 ... Yes (1.28)
Checking if you have Test::More 0 ... Yes (1.302177)
Checking if you have ExtUtils::MakeMaker 6.58 ... Yes (7.44)
Checking if you have Data::Dumper 0 ... Yes (2.174)
Checking if you have DBI 1.623 ... Yes (1.643)
Checking if you have Test::NoWarnings 0 ... Yes (1.04)
Configuring DBD-Oracle-1.80
Running Makefile.PL
Using DBI 1.643 (for perl 5.032000 on darwin-thread-multi-2level) installed in /usr/local/Cellar/perl/5.32.0/lib/perl5/site_perl/5.32.0/darwin-thread-multi-2level/auto/DBI/
Configuring DBD::Oracle for perl 5.032000 on darwin (darwin-thread-multi-2level)
If you encounter any problem, a collection of troubleshooting
guides are available under lib/DBD/Oracle/Troubleshooting.
'DBD::Oracle::Troubleshooting' is the general troubleshooting
guide, while platform-specific troubleshooting hints
live in their labelled sub-document (e.g., Win32
hints are gathered in 'lib/DBD/Oracle/Troubleshooting/Win32.pod').
Trying to find an ORACLE_HOME
Your DYLD_LIBRARY_PATH env var is set to ''
The ORACLE_HOME environment variable is not set and I couldn't guess it.
It must be set to hold the path to an Oracle installation directory
on this machine (or a machine with a compatible architecture).
See the appropriate troubleshooting guide for your OS for more information.
ABORTED!
-> N/A
-> FAIL Configure failed for DBD-Oracle-1.80. See /Users/username/.cpanm/work/1608142485.48272/build.log for details.
I've read here that ORACLE_HOME should be set to the value of the directory that contains the /bin directory but I can't find any /bin.
macOS is always changing, but on Mojave I installed Instant Client from the DMGs and then did:
brew install perl
ln -s $HOME/Downloads/instantclient_19_8 $HOME/instantclient
export DYLD_LIBRARY_PATH=$HOME/instantclient
cpan -i -T DBI
cpan -i -T DBD::Oracle
In general, never set ORACLE_HOME for Instant Client. (It can cause the wrong config files to be read). ORACLE_HOME is used for a 'full' database or full client installation, not for Instant Client. However some installers still reference the variable to find build files, so you will need it - at least at build time. DBD::Oracle will internally search for Instant Client and use $HOME/instantclient if $ORACLE_HOME isn't set.
macOS has gradually removed the usefulness of DYLD_LIBRARY_PATH, since it isn't propagated to subshells. This means it can't reliably be used. On Mojave I found I could alternatively copy the Instant Client libraries to $HOME/lib/ and didn't need to set DYLD_LIBRARY_PATH.
Side note: if you're using DBD::Oracle you don't need the Instant Client ODBC package.
Christopher Jones answer was not enough for me (macOS Monterey 12.2, Apple M1 Pro). The installation stopped with
./Oracle.h:37:10: fatal error: 'oci.h' file not found
To fix this, installation of Oracle SDK Package was required https://www.oracle.com/database/technologies/instant-client/macos-intel-x86-downloads.html#ic_osx_inst
Second comment:
export DYLD_LIBRARY_PATH=$HOME/instantclient
does not work (see Bash variable of name starting with 'DYLD' is not loaded into environment: bug or feature? )
==================================================
But this is not the end-of-the-problem. The installed DBD::Oracle can not be used. It fails:
Can't load '/Users/myname/.perlbrew/libs/perl-5.34.1#eien6/lib/perl5/darwin-2level/auto/DBD/Oracle/Oracle.bundle'
for module DBD::Oracle: dlopen(/Users/myname/.perlbrew/libs/perl-5.34.1#eien6/lib/perl5/darwin-2level/auto/DBD/Oracle/Oracle.bundle, 0x0001):
symbol not found in flat namespace '_OCIAttrGet' at
/Users/myname/perl5/perlbrew/perls/perl-5.34.1/lib/5.34.1/darwin-2level/DynaLoader.pm line 197.
Is this related to the MacOS SIP mechanism ? How to use DBD::Oracle ?
brew install openresty --with-debug --conf-path=/usr/local/nginx/conf/nginx.conf
but it no effect.
nginx -V
nginx version: openresty/1.9.7.4 (no pool)
built by clang 7.3.0 (clang-703.0.31)
built with OpenSSL 1.0.2h 3 May 2016
TLS SNI support enabled
configure arguments: ......--conf-path=/usr/local/etc/openresty/nginx.conf --http-log-path=/usr/local/var/log/nginx/access.log --error-log-path=/usr/local/var/log/nginx/error.log --with-pcre --with-pcre-jit --with-dtrace-probes --with-http_ssl_module
the nginx.conf file location not changed,still is the default.
The option you have specified --conf-path is not a homebrew supported option. You can see that by running this:
brew options openresty
Output
--with-debug
Compile with support for debug logging but without proper gdb debugging symbols
--with-geoip
Compile with ngx_http_geoip_module
--with-gunzip
Compile with ngx_http_gunzip_module
--with-iconv
Compile with support for converting character encodings
--with-postgresql
Compile with support for direct communication with PostgreSQL database servers
--with-stub_status
Compile with ngx_http_stub_status_module
--with-webdav
Compile with ngx_http_dav_module
--without-luajit
Compile *without* support for the Lua Just-In-Time Compiler
I think the only way to do what you want is to edit the formula, so you would do:
brew edit openresty
and then search down for conf-path, and edit the part that looks like this:
args = [
"--prefix=#{prefix}",
"--pid-path=#{var}/run/openresty.pid",
"--lock-path=#{var}/run/openresty.lock",
"--sbin-path=#{bin}/openresty",
"--conf-path=#{etc}/openresty/nginx.conf", <--- HERE
"--http-log-path=#{var}/log/nginx/access.log",
"--error-log-path=#{var}/log/nginx/error.log",
"--with-pcre",
"--with-pcre-jit",
"--with-cc-opt=#{cc_opt}",
"--with-ld-opt=#{ld_opt}",
]
You may need to do:
brew tap homebrew/nginx
before running the above commands.
Is Canonical renaming symbols in their package version of openssl, and if so for what purpose? When I compile openssl-1.0.0e.tar.gz (downloaded from openssl.org directly) from scratch I see the necessary symbol, but Python (and I) can't seem to find it in the packaged version.
Read on for more information about how I diagnosed this problem...
I am trying to compile Python 2.6.1 on Ubuntu 11.10, and get the error message above. The reason I am using this older Python is that I am trying to make my Ubuntu installation 100% compatible with a production system for development purposes.
When performing
strace -feopen make -j4 |& grep "libssl"
I see that I am using a promising file:
[pid 22614] open("/usr/lib/x86_64-linux-gnu//libssl.so", O_RDONLY) = 7
Running nm, this file has no symbols. However the .a file does have a similar one:
0000000000000030 T SSLv23_method
The package libssl1.0.0-dbg is installed via synaptic, however when I list the installed files for this package all I see is "The list of installed files is only available for installed packages" which is clearly an Ubuntu bug. So I am not sure how I am supposed to check which symbols are present in the .so.
However, I am suspicious that they have renamed SSLv2_method to SSLv23_method in any case.
How to proceed to figure out the status of Ubuntu's openssl-1.0.0?
The Ubuntu people build OpenSSL without SSLv2 support because the protocol has known security issues. So that's why you can't find SSLv2_method in their library even though you can find it when you compile the library yourself.
Ubuntu build logs are publicly available. You can see in the oneiric-i386.openssl_1.0.0e log that the library gets configured with the -no-ssl2 option, which disables support for SSLv2.
./Configure --prefix=/usr --openssldir=/usr/lib/ssl --libdir=lib/i386-linux-gnu no-idea no-mdc2 no-rc5 zlib enable-tlsext no-ssl2 debian-i386
Configuring for debian-i386
no-gmp [default] OPENSSL_NO_GMP (skip dir)
no-idea [option] OPENSSL_NO_IDEA (skip dir)
no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
no-md2 [default] OPENSSL_NO_MD2 (skip dir)
no-mdc2 [option] OPENSSL_NO_MDC2 (skip dir)
no-rc5 [option] OPENSSL_NO_RC5 (skip dir)
no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir)
no-shared [default]
no-ssl2 [option] OPENSSL_NO_SSL2 (skip dir)
no-store [experimental] OPENSSL_NO_STORE (skip dir)
no-zlib-dynamic [default]
Note that the availability of SSLv23_method does not mean that a client will be able to connect to a server with SSLv2. The OpenSSL documentation briefly discusses this situation:
The list of protocols available can later be limited using the
SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1 options of the
SSL_CTX_set_options() or SSL_set_options() functions. Using these
options it is possible to choose e.g. SSLv23_server_method() and be
able to negotiate with all possible clients, but to only allow newer
protocols like SSLv3 or TLSv1.
I was able to build Python 2.6 with SSL support on Ubuntu 12.04 with the help of the patch in this blog post.
My fix was install openssl without ssl2 support
./config --prefix=/usr enable-shared -no-ssl2
Then install anything linked to the libraries in /usr/ssl. It works..
I tried building openssl 1.0.1l (https://www.openssl.org/source/openssl-1.0.1l.tar.gz) binaries on Windows with following configuration command Configure no-ssl3 VC-WIN32 followed by ms\do_ms and nmake -f ms\ntdll.mak.
It successfully builds the binaries but when I try make a request using SSL3 it was successful.
Can anyone please help me to disable SSL3 on 1.0.1l branch of openssl.
Note: Using same command on openssl 1.0.1j disabled ssl3 from binaries and so when I use ssl3 request it quits (which is expected)
This is a bug in 1.0.1l and before, which is fixed in OpenSSL 1.0.2.
Reference:
*) Build option no-ssl3 is incomplete.
When OpenSSL is configured with "no-ssl3" as a build option, servers
could accept and complete a SSL 3.0 handshake, and clients could be
configured to send them.
(CVE-2014-3568)
[Akamai and the OpenSSL team]
Maybe the configuration was changed by this?
no-ssl3 configuration sets method to NULL (CVE-2014-3569)
no-ssl3 configuration sets method to NULL (CVE-2014-3569)
Severity: Low
When openssl is built with the no-ssl3 option and a SSL v3 ClientHello is
received the ssl method would be set to NULL which could later result in
a NULL pointer dereference.
This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8.
OpenSSL 1.0.1 users should upgrade to 1.0.1k.
OpenSSL 1.0.0 users should upgrade to 1.0.0p.
OpenSSL 0.9.8 users should upgrade to 0.9.8zd.
This issue was reported to OpenSSL on 17th October 2014 by Frank Schmirler. The
fix was developed by Kurt Roeckx.
I'm compiling libcurl for mingw32 as follows:
./configure --prefix=/Users/daniel/mingw32 "CFLAGS= -ABI=32"
make
make install
But when compiling a program using mingw32-gcc:
i386-mingw32-gcc -lcurl -o bin/remote-win.exe remote.c
i get:
In file included from /Users/daniel/mingw32/usr/local/include/curl/curl.h:34,
from remote.c:6:
/Users/daniel/mingw32/usr/local/include/curl/curlbuild.h:152:26: sys/socket.h: No such file or directory
In file included from /Users/daniel/mingw32/usr/local/include/curl/curl.h:34,
from remote.c:6:
/Users/daniel/mingw32/usr/local/include/curl/curlbuild.h:165: error: syntax error before "curl_socklen_t"
In file included from /Users/daniel/mingw32/usr/local/include/curl/curl.h:35,
from remote.c:6:
/Users/daniel/mingw32/usr/local/include/curl/curlrules.h:143: error: size of array `__curl_rule_01__' is negative
/Users/daniel/mingw32/usr/local/include/curl/curlrules.h:153: error: size of array `__curl_rule_02__' is negative
I'm pretty sure the error is because curl_socklen_t does not exist on windows. I've tried --target=--mingw32 but still no success.
Please help
End of configured for:
curl version: 7.21.4 Host setup:
x86_64-apple-darwin10.6.0 Install
prefix: /Users/daniel/mingw32
Compiler: gcc SSL support:
enabled (OpenSSL) SSH support:
no (--with-libssh2) zlib
support: enabled krb4 support:
no (--with-krb4*) GSSAPI
support: no (--with-gssapi)
SPNEGO support: no
(--with-spnego) TLS-SRP support: no
(--enable-tls-srp) resolver:
default (--enable-ares /
--enable-threaded-resolver) ipv6 support: enabled IDN support:
no (--with-libidn) Build
libcurl: Shared=yes, Static=yes
Built-in manual: enabled Verbose
errors: enabled (--disable-verbose)
SSPI support: no
(--enable-sspi) ca cert bundle: no
ca cert path: no LDAP support:
enabled (OpenLDAP) LDAPS support:
enabled RTSP support: enabled
RTMP support: no
(--with-librtmp) Protocols:
DICT FILE FTP FTPS GOPHER HTTP HTTPS
IMAP IMAPS LDAP LDAPS POP3 POP3S RTSP
SMTP SMTPS TELNET TFTP
Seems like mingw have no sys/socket.h. Just checked on my fresh mingw native install.
So, your application is not portable to mingw (or configure run was wrong). May be you should search or ask in Mailing List at http://curl.haxx.se
Thanks for your configure output. You did configed the curl for MacOSX itself, not for a cross-build for mingw. Your should force configure to use mingw's gcc, also you should to add cross-compilation options (at least '--target' option).