I am currently using:
OS X Yosemite 10.10.5
newest Indy (10.6.2.0, download 2016 March 13 - Indy10_5346.zip)
Lazarus 1.4.4
newest openssl
OpenSSL is more specificly:
openssl-1.0.2g accordingly to home brew cmd line interface
placed in /usr/local/Cellar/openssl/1.0.2/lib/
lib files in above directory are: libcrypto.10.dylib,
libcrypto.1.0.0.dylib, libcrypto.dylib, libcrypto.a,
libssl.1.0.0.dylib, libssl.dylib, libssl.a
...
I am passing above pah to Indy using idOpenSSLSetLibPath() befoe using Indy.
but I am getting getting error: EIdOSSLCouldNotLoadSSLLibrary at:
TIdSSLIOHandlerSocketOpenSSL.Init() -> TIdSSLContext.Create()
...
LoadOpenSSLLibrary() -> IdSSLOpenSSLHeaders.Load()
...
Load()
...
hIDCrypto := LoadSSLCryptoLibrary() -> Result := HModule(HackLoad(...))
...
Result := LoadLibrary(HackLoadFileName(ALibName,ALibVersions[I])); // always zero :(
Comments
"GIdOpenSSLPath + SSLCLIB_DLL_name are correct (file extension set correctly by Indy when using "HackLoadFileName" in "LoadLibrary" call)
Indy tries to iterate/load over following names: libcrypto, libcrypto.1.0.0, libcrypto.10, libcrypto.1.0.1, libcrypto.1.0.2
...
Side question #1:
why does homebrew ship openssl 1.0.2g in a file called
libcrypto.1.0.0.dylib - is it to maximize compability?
...
Thoughts on possible cause #1:
Could all this be an issue of Lazarus compiles 32bit for OS X? And OpenSSL is 64bit?
Install openssl like this in command line: brew install openssl --universal
This ensure the library works both for 32 and 64 bit apps.
You may need to uninstall first using: brew uninstall openssl
Related
I'm trying to install virtuoso's stable/7 branch manually from https://github.com/openlink/virtuoso-opensource. However, when I run ./configure, I get this error message after about 30 seconds:
checking OpenSSL version... configure: error: OpenSSL version 0.9.8e or greater is required.
The thing is, I do have OpenSSL. When I type openssl version -a in my terminal, I get this output:
benjhatch#benjamins-mbp virtuoso-opensource-stable-7 % openssl version -a
LibreSSL 2.8.3
built on: date not available
platform: information not available
options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: information not available
OPENSSLDIR: "/private/etc/ssl"
Why is it saying I need an openssl version of 0.9.8e or greater? Is there any way to fix this?
This is on a Mac that runs MacOS Catalina version 10.15.3.
The issues has been resolved in the default Virtuoso open source develop/7 branch from:
https://github.com/openlink/virtuoso-opensource/tree/develop/7
which now supports LibreSSL which is what is shipped as the only SSL library available for the the latest macOS versions ...
I have a go application I am trying to distribute using Homebrew. When compiling without Homebrew everything works as expected. When using Homebrew I get a compile error.
Compile Error:
cannot load DWARF output from $WORK/github.com/libgit2/git2go/_obj//_cgo_.o: decoding dwarf section info at offset 0x0: too short
This can be replicated by building my repo (which uses libgit2) on a mac from homebrew using:
$ brew install jwaldrip/utils/git-get -v --HEAD
The formula can be viewed at:
https://github.com/jwaldrip/homebrew-utils/blob/master/git-get.rb
The Makefile the formula uses at:
https://github.com/jwaldrip/git-get/blob/master/Makefile
I'm trying to give HsOpenSSL a whirl on Mac OS X, and it's blowing up in my face.
The latest Hackage version (HsOpenSSL-0.10.3.3) builds and imports, but doing anything with it kills my GHCi (both 7.6.3 and 7.4.2):
ghci> import OpenSSL
ghci> withOpenSSL $ do undefined
$ # Now I'm looking at a shell prompt
I put together an executable and built it with GHC, and voilà, a segfault:
$ ./test
Segmentation fault: 11
I'm using the version of OpenSSL that comes with OS X 10.8:
$ openssl version
OpenSSL 0.9.8r 8 Feb 2011
(I've also now installed the latest version of OpenSSL, v1.0.1e, and built HsOpenSSL against it. Again it builds and imports fine, but segfaults on any call out to OpenSSL.)
This is likely a problem with OpenSSL, or with some idiosyncrasy of using OS X rather than Linux, but my installation does work fine with Python's OpenSSL library. ...
Can anyone replicate this, or give me any debugging tips?
I'm afraid I have another negative report - it works here for me, on OS X. Hypothetically, I might be using a version that I might not be allowed to mention, though, so that could be the difference...
module Main (main) where
import OpenSSL
main :: IO ()
main = withOpenSSL $ do
putStrLn "Hm."
Then I can run it with:
$ ghc Crash.hs
... [it compiles] ...
$ ./Crash
Hm.
And it succeeds. I'm using GHC 7.6.3, HsOpenSSL 0.10.3.3, and OpenSSL 0.9.8y, this last dated 5 Feb 2013.
I am attempting to install the Cairo package in the development version of R on Mac OS X 10.7.4, but I'm running into an issue that I cannot resolve.
I have installed Cairo with homebrew (i.e., brew install cairo) and received the following message:
==> Caveats This formula is keg-only, so it was not symlinked into /usr/local.
Mac OS X already provides this program and installing another version
in parallel can cause all kinds of trouble.
The Cairo provided by Leopard is too old for newer software to link
against.
Generally there are no consequences of this for you. If you build your
own software and it requires this formula, you'll need to add its lib
& include paths to your build variables:
LDFLAGS -L/usr/local/Cellar/cairo/1.12.2/lib
CPPFLAGS -I/usr/local/Cellar/cairo/1.12.2/include
With the above message in mind, I attempted to install the Cairo package from R-Forge with the following R command:
install.packages("Cairo", repos="http://www.rforge.net/", configure.args = c("CAIRO_LIBS=/usr/local/Cellar/cairo/1.12.2/lib", "CAIRO_CFLAGS=/usr/local/Cellar/cairo/1.12.2/include/cairo"))
I receive the following error:
checking cairo.h usability... no
checking cairo.h presence... no
checking for cairo.h... no
configure: error: Cannot find cairo.h!
Please install cairo (http://www.cairographics.org/) and/or set
CAIRO_CFLAGS/LIBS correspondingly. ERROR: configuration failed for package ‘Cairo’
I repeated the same command without the repos argument (by default, I use the FHCRC mirror) with the same result.
At this point, the problem seems obvious: the file cairo.h is not present. But then I listed the files in the include/cairo directory. Here's the response:
ls /usr/local/Cellar/cairo/1.12.2/include/cairo
cairo-deprecated.h cairo-ft.h
cairo-ps.h
cairo-script-interpreter.h
cairo-svg.h
cairo-xcb.h
cairo-xlib.h
cairo-features.h
cairo-pdf.h
cairo-quartz.h
cairo-script.h
cairo-version.h
cairo-xlib-xrender.h
cairo.h
So, I'm pointing the installation of the Cairo package to the appropriate place, but the error persists. I have tried variations, such as CAIRO_CFLAGS=/usr/local/Cellar/cairo/1.12.2/include, with no luck.
Thoughts? Any help you can provide is greatly appreciated.
In case it's necessary, here is my sessionInfo:
R Under development (unstable) (2012-08-08 r60208) Platform: x86_64-apple-darwin11.4.0 (64-bit)
locale: [1]
en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages: [1] stats graphics grDevices utils
datasets methods base
other attached packages: [1] BiocInstaller_1.5.12
loaded via a namespace (and not attached): [1] tools_2.16.0
I had similar issue with cairo config error, and I already installed cairo with homebrew. Try below
brew install pkg-config
This solved mine problem.
A coworker and I just fixed the problem by ignoring all of what I typed above. Rather, we installed Cairo and all of its dependencies from source manually, thereby bypassing the usage of brew or variants like port. This worked like a charm, so I am not entirely sure what was wrong above.
After trying everything listed here, I found this blog post about installing the "full R package" using brew: https://luispuerto.net/blog/2018/05/11/installing-r-with-homebrew-with-all-the-capabilities/
What finally worked for me was building R explicitly with cairo (brew's default R tap uses --without-cairo and simply editing the tap did not solve the issue for me).
Works like a charm for me with R 4.0.2, cairo 1.16.0_3 under macOS Catalina 10.15.6.
I have installed the latest Haskell Platform for MAC OSX and I get the error "Setup: failed to parse output of 'ghc-pkg dump'" when I do anything with Cabal.
So I looked at my versions:
ralphtq$ ghc-pkg list Cabal
/Library/Frameworks/GHC.framework/Versions/612/usr/lib/ghc-6.12.1/package.conf.d
Cabal-1.8.0.2
ralphtq-mac-mini:cabal-install-0.6.4 ralphtq$ cabal --version
cabal-install version 0.6.2
using version 1.6.0.3 of the Cabal library
This is telling me that even though I have Cabal 1.8 the cabal-instal is at version 0.6.2. I have tried to correct that using darcs to get the latest version of cabal-install, but I cannot get passed the error:
ralphtq$ sh bootstrap.sh
Checking installed packages for ghc-6.12.1...
parsec is already installed and the version is ok.
network is already installed and the version is ok.
Cabal is already installed and the version is ok.
mtl is already installed and the version is ok.
HTTP is already installed and the version is ok.
zlib is already installed and the version is ok.
cleaning...
Linking Setup ...
Configuring cabal-install-0.9.1...
Setup: At least the following dependencies are missing:
Cabal ==1.9.*
It is expecting Cabal to be >= 1.9.
I tried to install a previous version of Cabal but got the following error:
...
...
[50 of 51] Compiling Distribution.Simple ( Distribution/Simple.hs, Distribution/Simple.o )
[51 of 51] Compiling Main ( Setup.hs, Setup.o )
Linking Setup ...
Configuring Cabal-1.6.0.2...
Setup: failed to parse output of 'ghc-pkg dump'
I am back to the same problem.
I have also tried a complete re-install of the platform.
What are my next options? Help appreciated, thx.
Either you have installed an old version of the Haskell Platform, or you have a mixed up environment where you have installed over the top of an existing, older install, and so now have a mixture of ghc-pkg versions from 6.10.x and 6.12.x
Try removing those ghc-pkg and cabal binaries, and then installing the Platform. That way you won't have those old executables lying around.