I installed the eggPlant15.20.rpm on our Linux/RedHat7 system, however seem not to take its license properly, causing it not launch at all.
I was wondering if the eggPlant RedHat installation is not sufficient, and whether we need other dependencies.
When running efls command to launch the License Panel, I see the below library messages:
[root#RHEL-BLD1 Library]# efls
/usr/GNUstep/System/Tools/gpbs: /usr/GNUstep/System/Library/Libraries/libjpeg.so.62: no version information available (required by /usr/GNUstep/System/Library/Libraries/libgnustep-gui.so.0.23)
/usr/GNUstep/System/Tools/gpbs: /usr/GNUstep/System/Library/Libraries/libjpeg.so.62: no version information available (required by /lib/libtiff.so.3)
[root#RHEL-BLD1 Library]#
Googling the above libraries does not provide much help.
Anybody knows the cause of the above problems?
Related
I'm attempting to build an image with the phytec bsp 18.2 from here: https://wiki.phytec.com/productinfo/phycore-i-mx7/bsp-yocto-fsl-imx7/
I require a newer version of systemd (> 234) and so am substituting the systemd recipe for version 234 from rocko, found here: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd?h=rocko by putting this in a custom layer. However, during the do_rootfs step, I receive an error that "No package provides libsystemd.so.0(LIBSYSTEMD_219). I've tried a work-around recommended here: Smart can't install...no package provides shared object file and it didn't solve the issue. I've tried echoing libsystemd.so.0, LIBSYSTEMD_219, and libsystemd.so.0(LIBSYSTEMD_219) to both ${rootfs}/etc/rpm/sysinfo/Providename and ${rootfs}/var/lib/rpm/Providename and had no luck. Does anyone have an idea on how to fix this? I'd appreciate any help that could be offered, and please let me know if I can offer any more information.
I don't know about the yocto wrapper, etc, but in standard RPM-land, this error:
Computing transaction...error: Can't install python3-systemd-234-r0.0#cortexa7hf_neon: no package provides libsystemd.so.0(LIBSYSTEMD_219)
means that there is a .so or executable in the RPM named python3-systemd-234-r0.0 that was compiled with a specific version of libsystemd.so.0 that had the flag LIBSYSTEMD_219. That flag is the "ELF Symbol Versioning" and it's seen most with GLIBC_XX when you try to install an RPM that's too new for a target system (e.g. CentOS 7 RPM on CentOS 6).
The systemd on your target machine is too old, so it only defines the versions it is compatible with, e.g. libsystemd.so.0(LIBSYSTEMD_210) or similar.
What you need to do is build your python3-systemd-234-r0.0 on a machine with the same version of systemd as the target (or cross-compile appropriately), or create a systemd RPM that includes the functionality you're attempting.
So you need to figure out how to apply one of these solutions to your build system; sorry I don't know enough about yocto to help there.
Our codebase is triggering this bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=13669
Therefore I need to compile GDB with the workaround hack, Unfortunately, I can't seem to find a list of configure options, or some kind of "enable all" flag.
I am using the CentOS 7 distro. The gdb included is version "Red Hat Enterprise Linux 7.6.1-100.el7" It seems to be installed to /usr/bin/gdb
The features I need is python pretty printing, as well as anything else eclipse might need under the hood.
This is my last attempt, but it still doesn't seem to have what i need.:
CC=gcc ./configure --with-python=yes --with-zlib
Specifically, eclipse still can't display pretty printed values.
Also, is there any way to overwrite the package installed version so that it "inherits" the configuration?
---edit---
Also, is there a good way to turn this into a yum installable package? Once i get this to work i need to distribute it to about 50 developer machines.
FYI the issue has been fixed: https://sourceware.org/ml/gdb-patches/2017-10/msg00836.html
On VirtualBox VM OpenBSD:
I was trying to build apr 1.5.1 in my attempt to build an apache 2.4 server WITHOUT packages( ie. from source ) and when I ran make test, testlock failed with:
testlock : -Line 300: Timer returned too late FAILED 1 of 4
...
*** Error 1 in test (Makefile:186 'check')
*** Error 1 in /a/b/c/d/e/f (Makefile:127 'check')
I have no idea what to do with it. What is the course of action for something like this?
You may want to try using a slightly older version of apr; perhaps one from an OpenBSD packages site (somewhere like this OpenBSD Packages site?)
Note: any downloads and installations that you choose to make from sites like these are your decision. Please make sure to read related documentation for compatibility information, too, before making a decision about installing software in your environment!
Also, your version of OpenBSD may make a difference for what package site would be best to use... the OpenBSD packages site above is just an example of what these sites may look like.
For future reference, you can find more information about these sort of packages in the OpenBSD packages and ports documentation.
The instructions how to install GoClipse have been followed.
I'm not getting any autocomplete stuff happening at all, either for local packages that I write, for built in stuff, or for GAE stuff (I have downloaded Go src to the SDK folder as the wiki states).
Are there any settings that I can check to ensure it is set up correctly? Is autocomplete supposed to work in the current version?
As the GoClipse with AppEngine article you linked to says:
We assume the reader has a working copy of GoClipse running in their Eclipse environment.
so that’s not the article you want to refer to. Instead, check for GoClipse.
The auto completion is named content assist in eclipse. The GoClipse features state:
Now delivered with content assist via Gocode for Windows, OS X 64bit, and Linux 64bit.
Gocode is an auto-completion daemon. So you will also have to install and run that one besides your eclipse + GoClipse.
There is a bug in the current version of Goclipse for the Linux platform. It currently delivers a prebuilt version of gocode for Windows, 64 bit OS X, and 64 bit Linux. I have only been able to test it locally with limited resources, so I really depend on users to report the problems they find at:
http://code.google.com/p/goclipse/issues/list
If you are having problems, I urge you to download and install gocode into your $GOROOT/bin directory and see if that helps. Otherwise, the fix will come in the next release in a few days.
Also, sorry for causing you any trouble and thank you for trying Goclipse.
If you are not using a gocode upstream (but the one shipped with Eclipse) on Linux you are also no be able to build your application with CRTL+F11, although just clicking in Run->Run is going to work.
So, I strongly recommend to update your gocode on Linux, as simple as:
$ sudo GOPATH=/opt/go/ go get -u github.com/nsf/gocode
I have installed Eclipse 3.5.2 and the plugin Subversion JavaHL Native Library Adapter 1.6.9.2 and this worked without any problems. However, this morning I was forced to change the password to logon to my Mac and since then I get the message that "Subversion native library not available" when I try to save any changes. Can anyone help? I have tried to add this line (-Djava.library.path=/usr/lib/jni) to the eclipse.ini file but this didn´t seem to make any difference.
Can anyone help?
Install MacPorts or HomeBrew, then run the following command:
For MacPorts, the commands to run are:
sudo port install subversion-javahlbindings +no_bdb +universal
For HomeBrew, the command is:
brew install --universal --java subversion
I was having a similar problem on Mac OS X Snow Leopard. I suspect your libraries are there but just need permissions changed, whereas I didn't have the libs at all.
The directory to check is /opt/subversion/lib, see if it has any libsvnjavahl files. In your case they may be there and just need new permissions.
To get the files I followed the the instructions they give for installing JavaHL on OS X, which is to download and install Open CollabNet. (login required, although it's free)
Then you just need to update your environment variable in .profile, something like:
export PATH=.:/opt/subversion/bin:$HOME/bin:$PATH
Then ran:
. .profile
Then I tested with javahltests.jar as mentioned here.
The easiest thing to do is download and install the OSX package that is provided on openCollabNet.
MacPorts also provides an easy Subversion and JavaHL package, however on Snow Leopard ?MacPorts is still compiling these packages as simple 32-bit binaries. If you use the default Snow Leopard JVM which is 64-bit you will get an error...
Failed to load JavaHL Library.
These are the errors that were encountered:
no libsvnjavahl-1 in java.library.path
no svnjavahl-1 in java.library.path
/opt/local/lib/libsvnjavahl-1.0.0.0.dylib: no suitable image found. Did find: /opt/local/lib/libsvnjavahl-1.0.0.0.dylib: mach-o, but wrong architecture
Note the error about wrong architecture. This is because the 64-bit JVM cannot load a 32-bit native library. The ?CollabNet binaries for OSX do not have this problem because they include both 32-bit and 64-bit versions.
Source: subclipse.tigris.org
Here is a blog entry that gives a solution:
http://blog.mattwoodward.com/getting-rid-of-subversion-native-library-not
I don't know whether this will work in your particular situation, but it's worth a try.
(Edited to fix link that became broken after I posted. The link became broken sometime between May 3 and June 1.)
In case you already have subversion installed I'd recommend performing first a brew uninstall and then the install again. And follow the steps to create the links indicated after the install concludes. This worked for me. Regards
I fixed it installing the SVNKit Client Adapter (not required) package.