Many software I have seen in open source projects, have just some versions with a r1 or r2 suffix, but it looks like Google is unable to find an answer.
It depends on how companies name the versions. Usually R could mean Release. Spring follows RC naming which means Release Candidate(RC).
I found this old SO thread - What is the difference between GA, RC and M2 release?
I found it is also often used as revision number.
E.G. Gentoo packages use rX to indicate a revision applying Gentoo specific patches to the package.
The answer #RolsonQuadras provided is nonetheless correct, too.
Related
The usual recommendation for handling the dependencies on Linux is by using the distro's package manager.
The good part of this approach is that you can reuse the basic set of libraries configured, tested, and updated for your system.
The bad part is that there are many distros with different package managers, and you probably have to support several of them. Users of not-so-popular distros have to work on their own to set up the dependencies.
The worst part is, when talking about games, some game distribution platforms ban the developer from using package files for installation.
Quoting itch.io,
.deb and .rpm packages (Oh no tier)
These are ignored when looking for uploads - it'll appear as if your app wasn't available on Linux at all.
Do not use these.
To not use the package manager, one way is to build the app on a reasonably old system, like Debian oldstable or the Steam Runtime (based on Ubuntu 12.04), and distribute the final software by copying the shared libraries depended upon.
My question is which shared libraries should be copy-distributed in this stage.
Do I have to ship libc? If I don't, is it guaranteed that newer versions of libc has backwards compatibility with older versions of libc?
Can I just be safe and ship all the dependencies? Will it work on most systems despite being a bit heavy?
If that's not a solution, which shared libraries should I include and which not?
Do I have to ship libc?
For reasons explained here, it is nearly guaranteed that your libc.so.6 will not be compatible with the system ld-linux.so (the path to system ld-linux.so is baked into your binary).
You could however use a shell wrapper to avoid this problem. Something along the lines of:
#!/bin/bash
TOP=/path/to/your/install
exec -a "mygame" "$TOP/lib64/ld-linux-x86-64.so.2" --library-path "$TOP/lib64" "$TOP/bin/mygame"
If I don't, is it guaranteed that newer versions of libc has backwards compatibility with older versions of libc?
Yes, GLIBC backward compatibility guarantees exactly that: you could copy a binary from a system of 10 or 20 years ago, and it will run on a freshly installed latest distribution1.
which shared libraries should I include and which not?
Note that by distributing GPL software you assume certain obligations. Talk to your lawyer if you plan to do that.
1There have been a few bugs about 15 years ago where this backward compatibility was broken in some specific cases, but you are unlikely to run into them.
I am using a shared C library on Linux that is distributed in binary form. The problem is that the dependencies are set to require exactly the versions available on the development machine. For example, each release requires the (at the time) latest glibc and only the exact version of libreadline on their system.
I have contacted the developers and they don't know what to do about this. As far as I can tell, they are not consciously using the latest features, so the library should continue to work with older dependencies. I think they are using gcc on Linux, but they are also using a complex make system to control other compilers to build for Windows and Unix.
How and to what extent can you manage the build process so that a library requires dependencies just of a sufficient version and will also accept later versions?
This was a related question.
Edit: To be clear, I want to know how to build programs so they will accept dependencies with a specific version number or later numbers. Whether the developers compile it or I do, I want to be able to distribute a binary that does not require exactly the versions of dependencies present in the build environment.
Edit 2: After rephrasing the question, I realized this has been covered many times before. Some of the best Q&A:
Deploying Yesod to Heroku, can't build statically
Compile with older libc
Linking against an old version of libc
How can I link to a specific glibc version?
It's not very confidence inspiring. They should be building on a stable baseline release, it could just be a virtual install. Some versions of Linux, copy a build environment so packages aren't linked to updated library versions.
The openSUSE build service, lets devolopers build binary packages, for a wide variety of http://openbuildservice.org/about/
IIRC readline is a GPL program and checking at http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html#Availability suggests it is GPL v 3 so they may be in violation of the GPL, if they are using libreadline functions and should provide you with the source to their library. I am not sure if you are meaning rpm/apt package dependencies, or their library is actually calling libreadline.
You can always extract files from rpm or apt packages, if necessary so avoiding software manager issues, caused by poor packaging.
Are there any differences between these two java versions. If there are any differences how can I have the version java version "1.4.2" because that is what I have in server.
1)
java version "1.4.2_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
2)
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM AIX
They are very different from the implementation point of view as the first one is from Sun and the second from IBM. Since they are from different vendors, the patch level means nothing (the _06 on the Sun JDK).
From a behaviour point of view, they should be the same. Having said that, I remember some issues in the past with the IBM jdk, in which it would perform really poorly.
If you want to use IBM's version of java, you can get it from here.
I suggest that you carefully compare the "bugs fixed" sections of the respective release notes for the respective versions.
Note that the release date for the 1.4.2_06 version is 2004-12-10 (according to the release notes), while the IBM version name is "20090307" which implies that it was built ~5 years later. While there is no guarantee that the IBM version has tracked all of the fixes to that date, it is a fair assumption that they will have (at least) tracked the security-related patches.
Reason why I posted this because when I tried to do some deployment to server from command line, I am having few issues so wonder this could be difference in java versions.
Possibly, but (IMO) it is more likely that the problem is nothing to do with the version of Java. Either way, I think that an enumeration of the differences is unlikely to help you isolate your problem.
I suggest that you ask a new Question in which you describe your actual problems. We may or may not be able to help ... but I think your chance of success is greater than with your current approach.
I'm new to MongoDB and just found out that the MongoDB driver from the Ubuntu repositories I've been checking out is not the same as the official driver. My question is, what are their differences? I usually go with the official version of things unless there is a good reason not to, but I thought perhaps there is a reason that the alternate driver is included in the Ubuntu repositories and not the official one.
The official MongoDB drivers are all to be found here:
http://www.mongodb.org/display/DOCS/Drivers
In addition, the official drivers all get moved under this root in Github:
https://github.com/mongodb/
That's the best way to get an up to date version of the driver. In terms of MongoDB and Ubuntu/Debian in general - the official packages are available as described here (Ubuntu repos have very old versions):
http://www.mongodb.org/display/DOCS/Ubuntu+and+Debian+packages
EDIT:
The driver you mentioned is this one:
https://github.com/algernon/libmongo-client
The driver maintainer mentions that it has "slightly different" goals from the main driver, but not what those are specifically. I think the main difference to look at is the level of maintenance and the frequency of updates:
https://github.com/algernon/libmongo-client/graphs/impact
https://github.com/mongodb/mongo-c-driver/graphs/impact
The official C driver is the basis for several of the other drivers, it is going to get a lot of developer time, quick bug fixes, immediate new feature support etc. The libmongo-client driver has not seen any activity in several months - I am not criticising here, just making the observation. For me, that alone would be a compelling reason why to use the official driver.
I am writing a C program. What I have seen from my earlier experiences is that I make some changes on a correct version of my program, and after that change, the program is computing incorrectly.
Now, for one occasion it may be easy to detect where I made that change and undo it or do it in some other way, and for other occasions I find it hard (with labor) to detect where exactly the problem is.
Can you suggest some platform or tool which allows you to put the new version and old version of the program side by side and mark the changes that were employed on the new version.
I am using gcc 4.3.2 to compile c programs on Ubuntu 10.04 OS.
Any suggestion is welcome.
regards,
Anup
Use a version control system. I recommend Subversion. This will allow you to compare your newer version with the older one to see exactly what changed and you can revert to the older working version if you break your code.
If you want a tiny, small, portable, one-file personal control version system, I can suggest fossil. A documentation is available here.
What you are requesting is some diff-like tool. There is a plethora of such tools, ranging from the diff command line utility to GUI frontend such as http://meld.sourceforge.net/. Most of these tools can be combined with (or have counterparts in) revision control systems as Subversion.
I would do this with some version control system, like Git. Refer to Git for beginners: The definitive practical guide if you're new to version control systems and/or git.
Thats the main purpose of all the version control management software.
I recommand to look at Subversion, GIT or Mercurial.
There are thousands of internet resources for this programs.
And they all have good comparision programs integrated in their GUI Tools.
Also, try to use Git/Mercurial/whatever together with Dropbox, it will allow you to continue developing on other computers. It will also teach you how to collaborate with others and with yourself.
This is slightly easier to do with the newer VCS systems like Git and Mercurial.
If you would use a version control system, such as Git or Mercurial, and follow a few good practices:
committing small, self contained changes (which includes committing, i.e. saving changes to version control, often)
committing known good state (or at least trying to, e.g. ensuring that code compiles before you commit)
you would be always able to go back to known good state.
If bug is/was in your current changes, you can compare current state with previous version: somewhere in changed lines there is bug... or something in changed lines uncovered an existing bug.
If bug was introduced by some earlied, unknknown commit, you can use bisect to search through history to find first commit that exhibits given bug: see for example git bisect manpage.
HTH