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?
Related
I don't exactly remember how my friend synched his changes in VS Code with remote machine(Gitlab). He commits, adds, changes the code in VS Code and it automatically applied to remote machine.
The problem is I don't remember exactly remaining part but sshXYZ userid#server
I don't remember the part XYZ but I know that ssh is secure encrypted connection to the remote server but I don't know the sshXYZ
I found what I was looking for. Actually, XYZ for 'fs' if in total then sshfs command.
Here is how to install it:
Install the latest version of WinFsp.
Install the latest version of SSHFS-Win. Choose the x64 or x86 installer according to your computer’s architecture.
Map Windows Drive using this URL: \sshfs\username#machine_ip....
Author of the following instructions can be found here
i trying to create a appimage for my Linux system. Using qt-creator i have completed the programing and ran the app successfully . but when i am trying to make it appimage using linuxdeployQt i am facing some errors
linuxdeployqt 5 (commit 37631e5), build 631 built on 2019-01-25 22:47:58 UTC ERROR:
The host system is too new.
Please run on a system with a glibc version no newer than what comes with the oldest still-
supported mainstream distribution, which currently is glibc 2.20.
This is so that the resulting bundle will work on most still-supported Linux distributions.
For more information, please see
https://github.com/probonopd/linuxdeployqt/issues/340
i don't know what this issue is. when i visit the website, it is not clear also. So anyone familiar with this kind please put your help here.
It means that your glibc is too new.
That's correct, to work around this issue while using linuxdeployqt you have to choose as build environment an older system such as Centos 6 or Ubuntu 14.04.
As an alternative, you can use appimage-builder which allows producing AppImages on newer systems.
It means that your glibc is too new. I think it is supported glibc version comes with Ubuntu 14.04 as it is mentioned in herr https://github.com/probonopd/linuxdeployqt/issues/340. I have faced the same problem and still struggling to solve this issue.
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
After working with Oracle databases and Apex for many years, I want to get some knowledge about Oracle forms & reports, because they are still quite widely used.
I've never seen Oracle forms & reports, so I want to create a development installation for learning purposes. Unfortunately installing Oracle forms seems a bit more tedious than I expected and I'm a bit stuck.
Windows installation
I first tried installing Oracle 12c (from http://www.oracle.com/technetwork/developer-tools/forms/downloads/index.html) on windows 7 x64. I installed the "Standalone forms builder", because when I chose "Forms and reports deployment", I got this error:
After installation I tried to start frmbld.exe, but immediately got this error:
FRM-91135: fatal error: message file D:\oracle\client\user123\product\12.1.0\client_1\forms\mesg\fmcus.msb not found
My oracle client is installed in that directory, but the mentioned file is certainty not there.
linux installation
Googling around I did not find any solution for this problem, so i decided to switch to a Linux virtual box machine. I installed Oracle linux x64 and then installed with a download from the same page again.
Once more I could only choose "Standalone forms builder", when I chose "Forms and reports deployment" I got exactly the same error as on windows. The installation ran successful.
After installation I tried to start formbuilder, this time I was presented this error:
./frmbld: error while loading shared libraries: libXm.so.3: cannot open shared object file: No such file or directory
So now I'm a bit stuck. My questions are:
Am I going the right way with the way I'm trying to install Oracle forms? or is there a better / easier way?
Do I need a "Forms and reports deployment" to be able to experiment with Oracle forms? or is the standalone installation the right way to go?
Are there any pre-installed virtual machines available for this? (I googled but couldn't find anything.)
Do I need a running Oracle database to be able to experiment with Oracle forms?
Linux installation:
Yes you are going the correct path installing Forms/Reports. There is no easier install method (Oracle does not have a prebuilt VM with Forms/Reports).
You will require an Oracle database to connect to.
To fix the linux error you will need to install additional OS packages, probably motif - you can run (to find the packages required): yum whatprovides libXm*
I have installed Forms Builder 12c (standalone install) on Fedora and it is working correctly.
The windows error might be related to you OS PATH ENV - if you have any other Oracle products installed, the PATH order may need to be changed, put the Forms related paths at the beginning.
Unfortunately I was unable to get it properly working with my previous attempts. In the end I restarted an installed a windows 10 x64 virtual machine, after which i followed these excellent video's to get everything working: https://www.youtube.com/watch?v=4tgtHPJGc7o
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).