When I visit the System environment section in the Install tool, TYPO3 will print:
PHP OpenSSL extension not working
But it won't tell me what the actual problem is. How can I find out the cause?
TYPO3 executes openssl_pkey_new() and only checks the return value, ignoring any actual errors.
To find out what the problem is, just execute the function yourself.
echo '<?php openssl_pkey_new(); ?>' | php 2>&1
Which might print an error like:
PHP Warning: openssl_pkey_new(): Error loading request_extensions_section section v3_req of /usr/lib/ssl/openssl.cnf in - on line 1
Which would indicate a problem with your OpenSSL configuration.
Just an addition as you might need to recompile your php installation.
I'm literally compiling my php 7.1.8 on a Mac Sierra with --with-openssl flag right now. I have come across with missing evp.h error during configuration. The way I solved this is to locate the evp.h, which is likely installed in several places. Take most relevant where openssl is installed, likely in /usr/local and use this as the optional directory:
./configure --with-open=/usr/local
I hope this helps.
Related
I'm trying to install Net::SSLeay with Carton.
The installation fails with this message
Configuring Net-SSLeay-1.90 Running Makefile.PL Do you want to run external tests?
These tests *will* *fail* if you do not have network connectivity. [n] n
*** Found LibreSSL-2.8.3 installed in /usr
*** Be sure to use the same compiler and options to compile your OpenSSL, perl, and Net::SSLeay. Mixing and matching compilers is not supported.
Checking if your kit is complete... Looks good
WARNING: /opt/homebrew/Cellar/perl/5.32.1_1/bin/perl is loading libcrypto in an unsafe way -> N/A
I've tried this with system perl, brew perl and multiple perlbrew perls.
Google came up with a temp solution to build homebrew using x86_64 architecture.
This did work for the libcrypto error, but gave me a whole different set of issues including mysql not running anymore.
Other "solutions" that I've tried are symlinking libssl & libcrypto as suggested by numerous other posts, all sadly without success.
Any ideas how to fix this or work around this without having to reinstall all brew packages as x86_64 ?
Quick Workaround
If you are looking for a quick workaround follow these steps.
Run carton bundle to create a vendor cache directory.
Go to cached tarball 'cache/authors/id/C/CH/CHRISN/' and unpack tar -xvzf Net-SSLeay-1.90.tar.gz
Edit Makefile.PL, change my $prefix = find_openssl_prefix(); to
my $prefix = '/opt/homebrew/opt/openssl#1.1'; ** adjust to your openssl location.
Save and create new tarball tar -czvf Net-SSLeay-1.90.tar.gz Net-SSLeay-1.90
Run carton install --cached to use the altered version
Hope this helps anyone in search of workaround
You can solve this in two steps:
upgrade ExtUtils::MakeMaker to at least version 7.58 (e.g. cpanm ExtUtils::MakeMaker)
install openssl via macports (sudo port install openssl) or homebrew (brew install --cask openssl)
After the Monterey update this broke again also on the x86_64 architecture, but just symlinking your latest openssl (where ever it is, depending how you have installed it) seemed to fix this. Example:
$ export OPENSSL_PREFIX=[find your openssl installation]
$ sudo ln -s $OPENSSL_PREFIX/lib/libssl.dylib /usr/local/lib/
$ sudo ln -s $OPENSSL_PREFIX/lib/libcrypto.dylib /usr/local/lib/
Better workaround:
I entered export OPENSSL_PREFIX=/opt/homebrew/opt/openssl#1.1 in my shell and then ran cpan. I checked the code in Makefile.PL and the first thing the function find_openssl_prefix does is to check the OPENSSL_PREFIX environment variable. If it is set, then it the function will return its contents.
Add the variable to your .profile, .cshrc, .bashrc, .zshrc, or whatever rc file your shell uses and you never have to worry about it again!!
I'm trying to get postgres server status with:
sudo /etc/init.d/postgres status -u postgres
But getting following error:
/home/alex/olddisk/usr/local/pgsql/bin/pg_ctl: error while loading shared libraries: libpq.so.5: cannot open shared object file: No such file or directory
I added:
export LD_LIBRARY_PATH=""
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/lib/"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/home/alex/olddisk/usr/local/pgsql/lib/"
to my .bashrc, but it didn't help.
Thank you.
I ran into this error when I built postgresql from source using the --prefix flag. Building from source installs the necessary shared libs to the libs folder under the prefix directory you specified, instead of the usual place installations put shared libs. To solve the problem I just added the [prefix].libs folder to the LD_LIBRARY_PATH environment variable. For example, after building postgres using --prefix /mike/sandbox/postgres, the below command solved the issue:
export LD_LIBRARY_PATH=/mike/sandbox/postgres/lib:$LD_LIBRARY_PATH
I think this issue is duplicated, I faced the same problem and posted a solution here.
try this:
1: Know the path of "libpq.so.5"
find / -name libpq.so.5
Output example: "/usr/pgsql-9.4/lib/libpq.so.5" If found nothing, check if you have already installed the suitable postgresql-libs for your postgresql version and your OS platform
2: Symbolic link that library in a "well known" library path like "/usr/lib":
ln -s /usr/pgsql-9.4/lib/libpq.so.5 /usr/lib/libpq.so.5
Attention: If your platform is 64 bit, you MUST also symbolic link to 64 bit libraries path:
ln -s /usr/pgsql-9.4/lib/libpq.so.5 /usr/lib64/libpq.so.5
3: Be happy !
Please ensure you have 'postgresql94' package installed as well (in addition to postgresql94-server, postgresql94-lib, postgresql94-devel and whatever other PG related package you already have). These libraries get installed along with that package.
Some ideas:
Your modified ~/.bashrc only takes effect when you start a new (interactive) shell. Though catching up on that will not help you because:
/etc/sudoers, your configuration file of sudo, probably specifies env_reset. This means, that /etc/init.d/postgres will not see the content of $LD_LIBRARY_PATH of your shell.
Insert debug statements in /etc/init.d/postgres to verify what I told you: echo "LDPATH: $LD_LIBRARY_PATH" >&2
Check /etc/init.d/postgres. Probably you will have to insert the third one of your export statements near the start of this script. Or you will have to update an existing export LD_LIBRARY_PATH= statement.
Have you installed the necessary libraries?
If you are using ubuntu try:
sudo apt-get install libpq libpq-dev
I want to install this varnish vagent2
https://github.com/varnish/vagent2
I am working around it but it is not installing.. it is giving me following error..
root#ns5 [/usr/local/src/vagent2-master]# ./autogen.sh
+ aclocal
configure.ac:65: error: pkg.m4 missing, please install pkg-config
configure.ac:65: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: error: echo failed with exit status: 1
now i have pkg-config / m4 / latest version of automake / autoconf installed...
yet it is giving this issue. Can anyone guide me as how can i get through the same ?
You're missing pkg.m4 it seems?
Check the spec files in the redhat/ directory to determine dependencies. We tested this on centos6 and I believe centos5, but I currently lack easy access to a machine to test from, so before I pursue this further, I suggest you check the spec file.
If that doesn't help, open an issue on github, as we don't generally follow stackoverflow :)
You need to install pkgconfig. On a mac, you may first need to install "mac ports" ... here is an article describing the solution:
http://www.fantageek.com/318/install-pkg-config-for-mac-osx/
Long story short. To get varnish-agent working happily on centos5 you needed to manually update automake and autoconf, which means that aclocal may not look into the right directory for pkg.m4.
Assuming you have installed pkgconfig using yum, line 22 in autogen.sh should look like this below.
aclocal -I /usr/share/aclocal
To make this a little easier, I have changed autogen.sh to include the above changes. See commit below, In addition, I have provided a Vagrantfile to illustrate how you can build a happy centos5 vm for varnish-agent. Hope this helps.
https://github.com/varnish/vagent2/commit/3921083f5fef12f06527e3361cc880121aa6b66b
I tried to install module Class-Load-XS-0.04 manually. I saw the following error:
$ perl Build.PL
Warning: ExtUtils::CBuilder not installed or no compiler detected
Proceeding with configuration, but compilation may fail during Build
However, the execution of perl -e 'use ExtUtils::CBuilder' was perfectly fine. I even tried to re-install ExtUtils::CBuilder, but it still does not work.
Could you please help?
I tried on my Win 7 machine, and it shows some warnings like this when I do perl Build.pl:
collect2: ld returned 1 exit status
Checking prerequisites...
requires:
! Class::Load is not installed
build_requires:
! Class::Load is not installed
! Module::Implementation is not installed
! Test::Fatal is not installed
! Test::Requires is not installed
ERRORS/WARNINGS FOUND IN PREREQUISITES. You may wish to install the versions
of the modules indicated above before proceeding with this installation
Then I installed the above mentioned modules, and things went fine then.
You may try install these modules first.
Hope it helps.
It looks to me like you don't have a compiler. Try this:
perl -e 'use ExtUtils::CBuilder; $cb = ExtUtils::CBuilder->new; print $cb->have_compiler ? "have\n" : "dont have\n";'
Can I guess that you are on Windows using ActiveState Perl? If so perhaps try Strawberry Perl which comes with a compiler.
Had a similar problem installing a different module (Win32::Mutex). This isn't a great fix, but it got the job done. From the build directory (e.g., ~/.cpan/build/The-Module-mYyzLx)
First, set the CC environment variable yourself
SET CC=C:\strawberry\c\bin\g++.exe [Windows]
export CC=/usr/bin/g++.exe [Cygwin]
and try to build (perl Build.PL, perl Build, ...). If it is still complaining about missing programs (g++, dlltool, etc.):
Second, copy pieces of your tool chain into the build directory
COPY C:\strawberry\c\bin\g++.exe . [Windows]
COPY C:\strawberry\c\bin\dlltool.exe .
cp /usr/bin/g++ . [Cygwin]
cp /usr/bin/dlltool .
If the build still complains about missing programs, copy those to your build directory too.
The fix and the symptoms are consistent with ExtUtils::CBuilder not being able to use the current PATH setting, though I have no idea what that would be so difficult.
I'd suggest installing these first:
apt-get install libc6-dev
and
apt-get install libtest-exception-perl
By the way you describe the problem it looks like you have these two perl modules missing. On the other hand it takes just a couple of seconds to double-check if those are installed, but these 'seconds' could help you save on a lot of head ache.
I am getting the following error when I trying to a run mex file in MATLAB:
??? Invalid MEX-file
'findimps3.mexa64':
/MATLAB/bin/glnxa64/../../sys/os/glnxa64/libgfortran.so.3: version `GFORTRAN_1.4' not found (required by /usr/lib/libblas.so.3gf)
Any ideas how to solve this problem?
update:
I found out that "strings MATLAB/.../libgfortran.so.3 | grep GFORTRAN" output GFORTRAN_1.0. I tried to changed libgfortran inside MATLAB but it didn't work. Not I think it's better to find a suitable libblas that works with GFORTRAN_1.0.
read this link, it explains how to configure matlab on some linux systems.
here the steps that are relevant to you:
To enable running external programs, […] fortran libraries need to be properly updated and linked. Look at the output of this command:
ll "$MATLABDIR/bin/glnxa64/"
It is likely that [this link] exist:
libgfortran.so.3 -> libgfortran.so.3.0.0
Search for [this library] on your machine:
locate libgfortran.so
[…] Update Matlab's links to point to these newer versions:
sudo ln -sf [location of libgfortran.so.3.0.0] "$MATLABDIR/bin/glnxa64/libgfortran.so.3"
I (think I) fixed this problem by running matlab with LD_PRELOAD, like this
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libfreetype.so:/usr/lib/x86_64-linux-gnu/libgfortran.so.3 matlab
Notice freetype was another library I was having a similar problem with.
In my case the following command worked:
sudo ln -sf /usr/lib/gcc/i686-linux-gnu/4.7/libgfortran.so /usr/local/MATLAB/R2012a/sys/os/glnx86/libgfortran.so.3
Matlab was complaining it couldn't find the GFORTRAN1.4 in the following location:
/usr/lib/gcc/i686-linux-gnu/4.7/libgfortran.so
So I linked this location to the library I had :
/usr/local/MATLAB/R2012a/sys/os/glnx86/libgfortran.so.3
I found the location of this library by using the locate command as given above:) Thanks for the help:)
In my case, fixed by
$ ln -sf /usr/lib64/libgfortran.so.3.0.0 /opt/matlab/sys/os/glnxa64/libgfortran.so.3
Errors I meet when using CDSP:
csdp: /opt/matlab/sys/os/glnxa64/libgfortran.so.3: version GFORTRAN_1.4' not found (required by /usr/lib64/atlas/libptf77blas.so.3)
csdp: /opt/matlab/sys/os/glnxa64/libgfortran.so.3: versionGFORTRAN_1.4' not found (required by /usr/lib64/atlas/libf77blas.so.3)
I just ran into the same problem (error usr/lib64/libgfortran.so.3: version `gfortran_1.4' not found) and it was actually not hard to fix. The problem seems to be that gfortran_1.4 version of libgfortran.so.3 comes from the release gcc-4.6.2 (i.e. fortran 4.6).
What I did was downloaded gcc-4.6.2 and built, using the steps: tar -xvf gcc-4.6.2.tar.gz cd gcc-4.6.2 ./contrib/download_prerequisites cd .. mkdir objdir cd objdir $PWD/../gcc-4.6.2/configure --prefix=$HOME/gcc-4.6.2 --enable-languages=c,fortran,c++,go make make install
Then, once everything was made, I went to the directory where the new, fresh libgfortran.so.3 was sitting (in my case it was /home/testuser/objdir/x86_64-unknown-linux-gnu/32/libgfortran/.libs/)
I copied this version of libgfortran.so.3, and went to the directory where my program was expecting to find libgfortran.so.3. I replaced the old one (the old libgfortran.so.3) with the new one (the one we just copied).
The problem instantly went away. I hope this helps you too!