I tried to install MonoDevelop on Suse 11.0 Enterprise, using the 1-click install on the MonoDevelop download page, but quickly wound up in a tangle of missing dependencies. I then tried using the Suse software repositories to get MonoDevelop, and waded through several of the dependencies for awhile trying to get the necessary packages to fulfill the dependencies, but some of the packages in the Suse repositories actually appear to be missing the needed RPM files. Are these repositories no longer being actively maintained?
I am aware that there is a CD on the Mono site (called the Mono LiveCD) that appears to contain a complete installation of the development environment, as well as a DVD for OpenSuse 11.2 (on the OpenSuse site) that might actually have all of the Mono software already installed. But the target environment for the utility I am writing is Suse 11.0 Enterprise Server. Does that matter?
What is the shortest distance between two points here?
that might actually have all of the Mono software already installed.
It has all of the Mono software installed ( of course it depends on what do you mean 'all') Last time when i tried it, the installation included Mono itself, monodevelop, MoMa and some software, written in Mono ( gome-do, for example ). I did not perform any additional steps for migrating my solution from a windows machine. the one thing worth to mention, monodevelop crashed several times, but i think it was memory-related ( an image had access only to 512 mb of RAM ).
But the target environment for the
utility I am writing is Suse 11.0
Enterprise Server. Does that matter?
In theory, it does not. You will have to check Mono versions of course, but i don't think you will face any problems during migration process. As far as i know, Suse 11.0 comes with Mono 2.0 pre-installed. With a latest life-cd you are going to develop using mono 2.6. There were some major changes ( partial LINQ to SQL suport ) you will have to compare changelog's of course.
If you're trying to install Mono on Suse Linux Enterprise Server, you need to download the Mono Extension Pack (available here). In SLES 11 it was separated out into a separate product in order to decouple the support life cycle from that of the general distribution. This allows them to release more often.
The add-on is available for x86, x86_64, and IBM System Z.
Related
Trying to use the nsocr (an OCR based application) shared library namely libjnsocr.so & it works successfully on a Ubuntu system. When running the same on a RHEL 5.1 box, I get an error as
ERROR_DLLNOTLOADED 0x70010002 or Cannot find or load the "NSOCR.dll" file.
One of the issues that might be the source is that Ubuntu runs on a recent version of Linux kernel i.e. 4.2 whereas the server where I am running the program is on kernel version 2.6 which is very old.
Please let me know if there is some way to make this file compatible for the older kernel. Appreciate any other inputs.
When running the same on a RHEL 5.1 box, I get an error as
... Would probably work if you used like Ubuntu 7.04 to create the
libraries / the application.
Say libjnsocr.so depends on e.g. libc6 version 2.11 or later. Redhat 5 has glibc-2.5 ( = libc6-2.5 ) : No chance that any contemporary application can work.
I have a box running Win2k to support a few legacy applications that can't be migrated forward at this point that I'd like to manage for most part with Cygwin.
However, the current Cygwin installer requires Windows XP 3. The installer referenced by the good folks at at Cygwin Time Machine runs just fine, but when I attempt to configure any suggested circa release area and proceed, the installer errors out attempting to download setup-2.bz2.sig and setup-2.ini.sig.
The circa release area I'm attempting to use is here.
Directory listing is not enabled, so really can't tell you anything more than the fact that setup-2.ini and setup-2.bz2 are there, but their signatures are not. Seems to be the case for a random sample of other releases listed here.
Cygwin Time Machine was enormously helpful in resolving this issue. Essentially, my woes were caused by
attempting to draw in packages from the Cygwin's 1.7 "development" branch (the setup-2.* errors).
using a setup installer too fresh for my purposes.
Digging around the Internet Archive, I found the last installation page update in which Windows 2000 (1 June 2013) still supported and downloaded the cached installer (link to setup.exe).
Cygwin Time Machine suggested these alternatives:
ftp://www.fruitbat.org/pub/cygwin/setup/snapshots/setup-2.602.exe
ftp://www.fruitbat.org/pub/cygwin/setup/snapshots/setup-2.573.2.3.exe
ftp://www.fruitbat.org/pub/cygwin/setup/snapshots/setup-2.523.exe
However, the 1 Jun 2013 installer (link) is considerably newer, can make use of a fresher repository (I'm able to install python 2.7.3 rather than 2.5.2), and has the nice filter feature we're used to in more modern installers.
Finally, Fruitbats does not archive the signatures for the setup package lists. You run at your own risk.
To ignore signatures, run the setup installer with an -X flag, i.e.:
c:\...> setup.exe -X
That about wraps it up. I have a mid-2013 Cygwin 1.7 installed on Win2k Advanced Server SP4.
What is the situation with JavaFX on Linux (x86 and x64)?
Can a JavaFX app be executed without problems on Linux OS?
I have found some questions from years 2011 and 2012, when apps were not stable!
The current version of JFX released is 2.2.4 and it is quite stable on Linux. However, it will become very much better when Java 8 would be released as it would contain JFX 8 distibution. You can try it yourself now using java 8 early access builds.
JavaFX 8 runs fine on Linux in my experience, the only requirement appears to be libgtk 2.18+. There are full details on Oracle JDK 8 and JRE 8 Certified System Configurations. Working Linux versions include:
Ubuntu 10.04 (and possibly earlier, 10.04 had libgtk 2.20)
Redhat 6
Possible problems you may encounter
3D scene support - requires specific modern GPUs + recent drivers, note there is no software rendering fallback for this, and no plans to - see mailing list question
Video playback requires certain version of libavcodec
OpenJDK does not yet include javafx, only the oracle distribution. Update July 2016 - openjfx package now available .on Ubuntu 16.04...
Javafx runs on JVM(Java Virtual Machine) like all other java applications. It doesn't matter whether you run the javafx application on windows or linux or mac there is no doubt that it will not run. That's why java is called platform independent language. Now stable version of javafx 8 has been released with more features.
I am thinking of kicking off a JavaFX project on my 64-bit Windows 7 machine. What I am doing is designing a full-screen console application. It's not interactive aside from a barcode scanner.
I'm designing this for what I think would be an Ubuntu laptop or some other Linux variation, although a different Windows OS is a possibility too (as well as 32 bit). From what I understand Java FX version 2.x has made great advancements in portability from its predecessor, but I wanted to ask the community here what their experience was in deploying JavaFX apps.
Have you had success using them on a variety of different architectures? What are some problems you have encountered?
Checkout EstiMate for an example of an all-in-one jar which is runnable via double click.
https://bitbucket.org/atill/estimate/downloads
It requires Java7u10 installed. I plan to make a proper installer for it later on, using the javafx maven plugin. https://github.com/zonski/javafx-maven-plugin. I haven't tested it on Linux or Mac but it does work across winXP 32bit and 64bit windows7.
As long as your barcode scanner works the same on ubuntu as on win and you are not using any external libraries, you won't notice the difference between those systems from your app.
I found installing oracle JRE on ubuntu the most difficult task. (with JRE_HOME, etc.) Even on Archlinux was easier than ubuntu.
Nevertheless, once the JRE is set, your app will run even on Raspberry Pi (which is ARM not x86)
Remember about file system differences between systems.
I have developed a small application in Qt Creator on Ubuntu 12.04 which I want should run on any other linux distro (mostly different versions of CentOS and ubuntu), just like any portable application on windows does.
I want to be able to simply share the binary file of the Application, and run the application.
I am able to successfully do this in windows, by just building the project in QT Creator and then putting the required libraries in the Application directory and then transfering them to other windows systems.
I searched all over and found out that I should be trying to build the project using LSB(Linux Standard Base) Compatibility, so that it runs on other linux distros. Is that the right way to do this?
I am very new to Qt and also to Linux (dont know much of Shell Scripting).
Thus, I dont know how I should proceed to make the Application LSB Compliant.
I have refered to, the following links:
Distributing Qt-based binaries on Linux and
Deploying Qt applications on Linux but have not beem able to understand what I am suposed to do.
I also found this question here which states a very similar situation as mine, but because I am a novice, I dont know how I should do this.
Moreover, considering that the first two articles were written 6 years back, shouldn't there be a simpler way to deploy Qt apps on the linux platform now?
I also saw something about static linking, is that the way to go?
Isn't there a way by which all of this can be done through Qt Creator itself?
If there is no hope of creating a portable Qt Application for Linux, then is there a way, say a shell script or something that would combine all the steps required to compile the Qt project on another computer and run it. Say, download Qt-SDK if not present, run qmake and make and then the newly compiled application, if not already there, so that the user can run the program just by running one script.
Your problem here is not the Linux Standard Base, but rather the presence or not of the specific version of Qt you need (or a later one).
Exactly like on a Windows machine, a user may have any of Qt installed, or they may not have it at all. On Windows it is easier to check for the presence of a certain version of Qt than it is on Linux, thus it is easier to write install tools that automate the experience.
To solve your problem there are a few ways:
Inform the user that your program requires a certain version of Qt or higher, and let the user handle the problem
Learn how to create packages for every distribution you want to target and create specific packages
Use a program like 0Install or Elf Statifier to create a package/executable containing all the necessary libraries.
The latter is similar to what many Windows and Mac programs do (they include every library they need within the installer), but it is not the preferred way on Linux, which relies heavily on shared libraries.
Making a binary application compatible with any other Linux distro is practically impossible since you will never know in advance which libraries are available in distro X, or what version of that library is available. Even among a single distro (e.g. Ubuntu), binary application are almost never backward-compatible, since anything built on Ubuntu 12.04 will have dependencies on versions libraries which are installed on that version of Ubuntu, and trying to run that binary on Ubuntu 10.04 will most probably fail simply because it doesn't have a recent enough version of glibc or some other necessary library.
However, the idea can be much more implementable if you limit yourself to a finite list of distros and versions of those distros. You can then know which libraries are available for those distros, and aim for the lowest common denominator. I used to maintain a binary application which had to support several distros (Ubuntu, Fedora, OpenSUSE, SLED, Mandriva), and the way I would do it is install the oldest distro I was targeting on my build machine. That way, the binary application would be linked to the oldest versions of the libraries available on those distros. Unless there's a new major version of such a library (which happens quite rarely, and even then, distros usually distribute the previous major version for a while for compatibility purposes), your compiled binary will then be compatible with all your targeted distros.
Therefore, the quick piece of advice I would give for your situation, use the oldest LTS version of Ubuntu which is still supported (10.04 at the moment) for your development, and you should be pretty safe for most recent popular distros. For the application you already developped on Ubuntu 12.04, you should have no problem simply recompiling the same source on 10.04. Understand that you will never however achieve 100% compatibility with a compiled C++ Qt application.
If Qt is not all that important to you, you could use a higher-level or interpreted language such as Python, Java, Perl or Ruby. With such languages, you can usually count on the language implementation already being installed on the target distro.
Deploy an application in Linux is a nightmare, luckily there are some solutions. Check this projects to build a portable binary with all their dependencies bundled:
http://statifier.sourceforge.net/statifier/main.html
http://www.magicermine.com/index.html
http://www.pgbovine.net/cde.html
Another solution is make a portable 0install package:
http://0install.net/
I recomend this solution. Personally I have been problems with the 3 first packagers.