i installed the pecl_http package.
My phpinfo says its enabled.
But i get this Error Message: Fatal error: Call to undefined function http_head()
Its Ubuntu 10.04.4
pecl_http changed completely between versions 1 and 2 - code that was written for version 1.x will not work with 2.x. For the functions that I had used from version 1 there wasn't even an equivalent in version 2 so I had to code those from scratch.
Details of version 2 can be found at https://mdref.m6w6.name/http
It is unfortunate that version 2 wasn't put in PECL as pecl_http2 as it's really a different library. To use any of the functions beginning http_ you'll need to use version 1 of the library. Install the last 1.x version with:
pecl uninstall pecl_http
pecl install pecl_http-1.7.6
Related
I am using Intellij IDEA 2017.2.5 on Linux Mint 18.2 and trying to add new openjdk-9 SDK but IDEA does not accept openjdk 9 as valid JDK:
I have installed all of my SDKs using apt-get from ppa standard repositories.
This is my update-alternatives --config java/javac output:
Although Intellij declared it would support JDK 9 here, but it seems it is not yet fully compatible with at least opensdk-9.
Maybe refactoring SDK directory and removing 'jre' folder misleads the IDEA to find the SDK 9 home folder.
Any idea why Intellij IDEA claims 'The selected directory is not a valid home for JDK' ?
“ Ubuntu PPA for OpenJDK” currently has very old build of openjdk-9(9~b115-1ubuntu1).
So the IDEA does not recognize it as a valid SDK.
I removed current installed version:
sudo apt-get remove '^openjdk-9.*'
Then I have downloaded newer .deb build(9~b181) files including jre,jre-headless,... from launchpad build archive.
sudo dpkg -i openjdk-9-jre-headless_9_b181-4_amd64.deb
openjdk-9-jre_9_b181-4_amd64.deb
openjdk-9-jdk-headless_9_b181-4_amd64.deb
openjdk-9-jdk_9_b181-4_amd64.deb
Just Execute the above command at a single line, line breaks are for better readability.
Ignore any error complaining about:
"Package libpng16-16 is not installed."
Next execute the following:
sudo apt-get install -f
Now after installing this build of openjdk-9 the IDEA is happy with SDK home.
Thanks #y.bedrov for his useful comment.
Update:
However this solution enables you to declare openjdk-9 in the mentioned IDEA version(2017-2) but you are not able to compile any class within the IDEA itself.
You can only compile your application with elder jdk and run it with openjdk-9. There is an other issue which indicates this here.
In the newer IDEA versions(I have tested 2017.3) this build of openjdk is not allowed to be used as new SDK any more, see this issue.
The short reason is an issue in Debian package which contains incorrectly compiled lib/jrt-fs.jar file.
See this Answer for more information
After installing Symfony 2 and check /config.php I got this notification:
intl ICU version installed on your system is outdated (55.1) and does not match the ICU data bundled with Symfony (57.1)
To get the latest internationalization data upgrade the ICU system package and the intl PHP extension.
How can I upgrade this?
I'm using Ubuntu 16.04
This is just a warning and you can safely ignore the message. I've response to similar questions on this. See this URL for more details:
https://github.com/symfony/symfony/issues/15007
Note: You'll also get the message when you run:
php bin/symfony_requirements
The message will say it's an "Optional recommendation".
EDIT #2
Based on your comments. You need to upgrade ICU. Sounds like you might be on Debian, and it might be possible to upgrade. Try these commands.
yum list available |grep icu
This shows what packages are available and searches for "icu". The second column shows the version. If there is a version that shows "57.1", then you should be able to use yum install to install it. Otherwise you would have to build and install on your system, which is much more difficult to give you a definite answer.
I am in the process of moving my programming from mac to the linux distrubution OpenSuse Leap.
therefor i want to install the c++ libraries which i used on my mac on my new machine, this is done through YaST (yet another setup tool)'s software manager, through which i have succesfully been able to install multiple libraries.
I am having problems installing GLFW3, i would prefer to install the latest version (3.2), but at the very least the version must be greater than 3
under YaST's software manager i can however only find something named GLFW2 - however it claims to be version 2.7.6-3.2-x86_64 and to have the build time Fri 11 Sep 2015, and i am not sure if i should regard the fact that it is quite recently build and that the current version (3.2) is in the supposed version of this as a proof that it is indeed GLFW version 3.2 - with some backward compatibillity, or if i should regard the fact that the library is named GLFW2 as a proof that is is not GLFW3.
I have attempted to make and compile dummy programs (which are totally empty programs which tries to include GLFW3) but they fail to compile, claiming that library GLFW3 doesn't exist, but i can not know wether or not they fail because GLFW3 is not installed, or because it is installed but I don't know how to include it.
My question is therefor: if i install the library named GLFW2 through YaST, can i then safely assume that i have GLFW 3.2 installed and that i therefor only need learn to include and compile the library; if no, does that mean i can't install a version of GLFW higher than 3
I have just the same problem today using OpenSUSE, and ended up installing GLFW3.2 from source. In order to get the glfw compiled from sources on OpenSUSE, I also needed to install the following dependencies (using zypper install package_name_to_install):
1) libXrandr-devel
2) libXinerama-devel
3) libXcursor-devel
After the dependencies are installed, I just followed standard cmake flow:
1) git clone git#github.com:glfw/glfw.git
2) cd glfw && mkdir build && cd build && cmake ..
3) make
4) sudo make install
I'm getting this error when i try to run apache:
./httpd: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory
when i do a search for the lib i receive this:
/usr/lib/libpcre.so.1
/usr/lib/libpcre.so.1.2.1
/usr/lib/libpcre16.so.0
/usr/lib/libpcre16.so.0.2.1
/usr/lib/libpcre32.so.0
/usr/lib/libpcre32.so.0.0.1
/usr/lib/libpcrecpp.so.0
/usr/lib/libpcrecpp.so.0.0.0
/usr/lib/libpcreposix.so.0
/usr/lib/libpcreposix.so.0.0.2
/usr/lib64/libpcre.so.1
/usr/lib64/libpcre.so.1.2.1
/usr/lib64/libpcre16.so.0
/usr/lib64/libpcre16.so.0.2.1
/usr/lib64/libpcre32.so.0
/usr/lib64/libpcre32.so.0.0.1
/usr/lib64/libpcrecpp.so.0
/usr/lib64/libpcrecpp.so.0.0.0
/usr/lib64/libpcreposix.so.0
/usr/lib64/libpcreposix.so.0.0.2
I tried to upgrade my pcre, to get the so.0 :
Package pcre-8.33-11.fc20.x86_64 already installed and latest version
Nothing to do
I'm out of ideas, hope someone can help.
This error is occurring because the version of Apache that is currently installed was built against an older version of pcre.
First upgrade Apache to the latest version in the Fedora repositories. The latest version should have been built against the newer pcre shared object.
If you can't, or won't upgrade Apache, you can downgrade the pcre package to the first version that contains libpcre.so.0, which is 7.8 I think.
If you need a quick fix and aren't using this web server for anything too serious you may be able to make it work by sym-linking libpcre.so.0 to libpcre.so.1.
lastly, you could rebuild Apache manually, which should use the pcre that is currently installed.
I have an rpm compiled in centos 5.x which requires libnetsnmp.so.10 and other shared objects. I want to create an rpm of it which is to be run on centos 6.x but it fails to install as on installation it says :
error: Failed dependencies:
libnetsnmp.so.10()(64bit) is needed and so on...
But Centos 6.x contains libnetsnmp.so.20
So I created symbolic links of libnetsnmp.so.10 of libnetsnmp.so.20.
But problem is still the same.
So can you please help me to resolve this problem?
If recompiling for Centos 6 isn't an option, you can try two things, first, install the correct libnetsnmp in the Centos 6 server. If that's not an option, you can add the following to your RPM spec file:
Autoreq: no
This will cause it not to scan your binary for dependencies (such as dynamically linked libraries), and automatically build that into the RPM.
Of course, if that version of libnetsnmp is ACTUALLY required, your just hosing yourself down the road, but likely newer versions will work just fine.