Running Quartus II on ReadHat Linux 9.0

Hello: I am not so surprised: this thread, has triggered lots of answers.

To me, this underline the need, for a given Linux application to be able to run on most "current" distributions. Or stated otherwise to be distribution independent.

If Altera (or any other vendors) do not want to do this, it is after all their choice to loose customers to vendors who will address waht seems to be a very common request. But I believe their concern is to have to test, and support their software on only one distribution, to make things possible.

Instead of having the (irrational in my view) position: "We support only this Linux" which inevitably will result in supporting the local Linux vendor (SUSE=Germany, REDHAT=US, MAndrake-France, etc...), I would suggest to rather support a "level" of Linux Kernel+Libraries.

A collateral advantage, would be for libraries and kernel developpers to evaluate if they did not break backward compatibility, by trying a few large applications.

In my view it is fine for vendor to test their distribution, only on one current version of Linux. (Current to me is latest and one before latest). I would advocate to use Debian, which is based on stability, rather than "bleeding edge", and is really open source. Unless I am mistaking it also uses unmodified Linux Kernels. (Commercial distributions tend to modify the kernel).

This will have the advantage to have Linux deliver what most of US want: freedom of choice, unlike proprietary operating systems.

To achieve this, could be either a fancy script, but I have to admit that I do not favor this: 1) portablility is not great, 2) Debugging can be hairy.

I am wondering if the best solution would not be, just a simple open source module written in C, which could do the necessary initialization (checking authorizations, setting of environment variables, openning of configuration files), and having this open source module, calling "Proprietary code" in object form.

This would allows user to develop and post on the net fancy installation files, specifics to a given distribution. Does this make sense?

Thanks for your attention.

Hi Petter,

The trouble is that you can check for version numbers and such, but not on actual capabilities when you get a distribution shoved in your face. Red Hat

IMHO, Quartus under Linux is pretty flexible when it comes to distributions. I've been using Quartus using Gentoo Linux on a 2.6.0-testX-mmY kernel for the last few months and I haven't had a single problem so far. The main issue that Altera has with Linux distros is supportability - which I have waived ;-) There's only so much useful Linux knowledge you can cram into a support engineer in any given timespan to solve issues, and I think that they made a fairly good, (maybe slighly US-centric) choice.

Best regards,

Ben

Hi Ben,

Unfortunately I don't have a lot of Posix threads experience so I can't comment on the version number checking. However, I think one should check for the functionality provided by the different versions rather than trying to extract their version numbers.

It might be possible to fork out two pre-compiled code segments which assume the functionality of the two thread libraries. One will crash (I guess you'll have to catch that sigv) and not return the correct result. The other will run and return the correct result. This way you should be able to tell which part of the installer has to use. Of course testing for a known kernel bug which will lock up the machine this way is not advisable :-)

OTOH I don't see why compiling a small program and see if it compiles, links, and run is that bad. This is what's taking place in the GNU autoconf script which many Linux users are quite familiar with.

Yes. But unfortunately it does not run on the x86-64 under SuSe 8.2 as I mentioned in an earlier message. I think it will run if the LD_LIBRARY_PATH etc. is set up correctly. This is a minor issue which I think would be simple to fix.

I don't think Altera should officially support all (or a large number of) Linux distributions. I think it's better to make sure it runs well under the officially supported version.

However, I hate to see software which checks if /etc/redhat-release matches a given string and bails out if it doesn't (it could give you a warning that you're running under a non-supported release). Again, they should check for the functionality required by the tool so that it could run under multiple distributions which provide the same libraries as the officially supported version. I think this will only get better over time as Linux becomes even more mainstream in the EDA world.

Petter