Well, I'm having some problems restarting my Apache Server. I modified the ulimit on the server but I'm failing to restart httpd;
I'm running the server on CentOS 5.8 x64. The output from httpd -V:
Server version: Apache/2.2.3
Server built: Jan 10 2013 08:19:28
Server's Module Magic Number: 20051115:3
Server loaded: APR 1.2.7, APR-Util 1.2.7
Compiled using: APR 1.2.7, APR-Util 1.2.7
Architecture: 64-bit
The error I'm getting when running /sbin/service httpd restart(I'm not going to print the hall output):
Syntax error on line 210 of /etc/httpd/conf/httpd.conf:
Syntax error on line 6 of /etc/httpd/conf.d/php.conf:
Cannot load /etc/httpd/modules/libphp5.so into server: libidn.so.11:
wrong ELF class: ELFCLASS32
I googled this error and tried to dig for the problem. What I found is that libphp5.so is 64-bit architecture whilst libidn.so.11 is 32-bit. Normally, as I know, there shouldn't be a problem using 32-bit programs on 64-bit architecture, but in this case there's 32-bit library used in 64-bit program(****See this related question**).
I tried to install the 64-bit version of the library but what I could find, for my O.S.(centOS 5.8) is the libidn_x86_64 version, which is again on 32-bit.
Programs installed on server:
squid - Proxy
ffmpeg - for video streaming
csf-lfd -> firewall
Apache
Any help on finding the problem is appreciated!
Since the version of libidn in CentOS 5.1 is the same as in 5.9 (indeed it's the same file), it's probably a safe bet that it will install in 5.8
could find, for my O.S.(centOS 5.8) is the libidn_x86_64 version, which is again on 32-bit.
No, the name implies it's the 64 bit version - if it contains a 32 bit object file, then something has gone way wrong - further, given the wide usage of CentOS and that libidn is required for all sorts of things, I'm sure someone would have noticed by now if the rpm contained the wrong file.
You might want to spend some time thinking about how your server got into this state. It shouldn't have been possible to install/upgrade the PHP from Centos respoitories with the right dependencies in place (unless you forced it to ignore them).
Related
I don't mean the version(s) provided by the various distributions but the binary from the official website.
I have an old VM running 32bit OpenSUSE 12.1 that is configured for a project I'm working on at work. I need to install WebKitGTK. The problem is that the cmake in the repositories is ancient 2.x, while WebKitGTK at least 3.6 (or similar). So I went to the official website and (my fault) without looking too much into it downloaded the 3.10 installation for Linux.
Upon executing the binary that was installed I got the error that the file could not be run. I checked the execution rights and it was fine. Then it struck me...I ran file cmake and got 64 instead of the required 32bit.
I went back to the website and all I could find were 32bit versions for Windows but none for Linux.
I can build it from source but just out of curiousity would like to know if support has been dropped. I was unable to find any information so far.
32-bit support for CMake hasn't been dropped. They just don't provide binaries for it on their website as of CMake 3.7.0
I am trying to get a small C application to run on my web server. The web hosting company is HostGator and we have their least-expensive plan 'Hatchling'
Unfortunately this particular plan does not provide access to a compiler, which means I'll need to build it on a similar machine to that server and transfer the executable there.
My question is how 'close' do I have to get to the Linux distribution on that web server for this to work? I currently have a recent Ubuntu in a VM and would like to use it for this process but maybe some complex differences in how Ubuntu compiler chain is built versus what can work on the web server are too great?
Would I need to install the CentOS release 6.5 they use and compile on that?
What do you recommend I do to attack this problem?
John,
P.S. Hostgator runs 'CentOS release 6.5 (Final)' and /proc/version returns "Linux version 3.2.52 (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) )"
It is worth checking that the architecture is the same e.g. Intel - 32bit or 64bit. In theory 32bit will work on a 64bit architecture as long as supporting libraries have been installed.
Dependancies are the other challenge you will have.
Versions of GCC and Kernel versions do not matter too much.
I have this version of Linux server:
-bash-3.2$ cat /proc/version
Linux version 2.6.18-194.11.1.el5 (mockbuild#hs20-bc2-3.build.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Tue Jul 27 05:45:06 EDT 2010
-bash-3.2$ cat /etc/*release*
cat: /etc/lsb-release.d: Is a directory
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
Currently, I am writing c program on the Linux side, I will need the server power to execute my program. I prefer IDE, but since my machine is Windows and what not, I have to compile the program remotely on the server. Sometimes, it's such a pain that I cannot run a stacktrace after the program crashes. And the thing is I want is to achieve higher productivity.
I can only access this server with PuTTY or the like, and I do not have the rights to install any software. And updating the software in the server is also not possible.
I see that the server got programs like Matlab that can output to XMing on the client side. (Ex. I can run Matlab as a GUI from the server side and have it display on my client device)
I see that some people suggest me for Eclipse, but the IDE is way too slow. In fact, it lowers productivity.
So is there any recommendation or a scheme that will allow me to compile, execute and debug my program remotely on the server with better ease-of-use, given the bold criteria above?
You cannot install as root, but maybe you can manually install applications in your user directory? With that and X11 forwarding you should be set (except a bit of latency).
Also, if you have gdb on the remote (which you probably do since you also have the compiler) you can see stack traces with it after enabling core dumps (ulimit -c unlimited), by opening the binary and the core file: gdb -c , then bt.
While trying to install the Subversion plugin I get this error when Eclipse starts:
Failed to load JavaHL Library.
These are the errors that were encountered:
no libsvnjavahl-1 in java.library.path
/usr/lib/jni/libsvnjavahl-1.so.0.0.0: /usr/lib/jni/libsvnjavahl-1.so.0.0.0: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch)
no svnjavahl in java.library.path
java.library.path = /usr/lib/jni
environment:
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
Java HotSpot(TM) Client VM (build 20.4-b02, mixed mode, sharing)
Linux debian 2.6.32-5-amd64 #1 SMP Mon Jan 16 16:22:28 UTC 2012 x86_64 GNU/Linux
I tried changing my java.library.path to a 64-bit lib but it doesn't help - I still go=et the same error (only last line changes - to a 64-bit path)
Also, I have no idea why it's looking in /usr/lib/jni/ even after I change the java.library.path.
I was annoyed by that message so I did this and it disappeared!
To solved just install the package with this command:
sudo apt-get install libsvn-java
and you must config eclipse.inito add path /jni
example :
-Djava.library.path=/usr/lib/x86_64-linux-gnu/jni
https://danangindrak.wordpress.com/2012/02/23/solved-memperbaiki-subclipse-error-default-svn-client-not-found-pada-eclipse/
OK I just ran into the same problem. I installed the javaHL lib but that didn't fix it alone. I was able to fix it by double checking which version of subversion I had installed in synaptic. I actually had 1.6.x while I installed the subclipse for version 1.8.x. so I started over, deleted my eclipse folder, extracted it and installed subclipse from the following eclipse update site: http://subclipse.tigris.org/update_1.6.x
more on the incompatibility:
http://subclipse.tigris.org/wiki/JavaHL
http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA
(get the one that says Links for 1.6.x Release:)
The problem is that you don't have libsvn-java installed. To solved just install the package with this command:
sudo apt-get install libsvn-java
and you are read use subclipse.
problem solved - the reason was that 64b Subversive SVN Connectors that were installed couldn't work with 32b JDK; I've re-installed eclipse to 32b version and everything is ok
I realize that I am attempting to go beyond the "supported" behavior of the manf's released drivers for Perl, after all they have only released it in package with x86 .so's.
However, since I cannot use their package with x64 Perl on a RHEL 5.4 x86_64 box, and maintaining a seperate install of x86 Perl just for this one package, I have made an attempt to get this puppy working thanks to released 64-bit .so's that accompany other driver packages for Advantage.
What I have done to this point:
download beta 10 DBI drivers, in 32
download beta 10 PHP extension (it contains 32 and x86_64)
copy the required DLLs into the ads-lib location (eg /usr/local/ads/lib64)
compile the Perl DBI driver with the path to the lib64's .so's
Good compilation, good install, good use.
The problem is that I always get :
failed: [iAnywhere Solutions][Advantage SQL][ASA] Error 6060: Advantage Database Server not available on specified server. axServerConnect (SQL-HY000)(DBD: db_login/SQLConnect err=-1)
Does anyone have any ideas?
EDIT: fixed package name in post title
EDIT: Updated title.
It appears that it's not just the x64 perl, but the RHEL 5.4 underneath that may be interfering. As commented below, I managed to shoe-horn a x86 perl onto the system, and compile the DBD::Advantage 9.99, and later replacing that with 9.10, and none of these x86 would connect either. Neither library (9.99 or 9.10) in either bit-edness will connect from this x86_64 server to the windows server's UNC path.
I have successfully mounted this share without problems, but still I cannot seem to connect to the 9.1. I have tried:
\hostname\PATH
\FQDN\PATH
\IP\PATH
and all of these variations with the port (default) 6262 included.
My windows machine connects fine, with both 9.1 and 9.99 from strawberry perl.
Check the host file on the Linux server and make sure the name of the server uses the actual IP rather then the loopback address.
Also, since you updated the client, did you also install/update the 10 beta server?
Finally, what is your connection string? Have you tried adding the port to the connection string?