ubuntu 7.10, fedora 8

[danmc]

has anyone tried running IC5141 or assura317 under either ubuntu 7.10
or fedora 8? I know they aren't the supported OS's, but it would help
if one of those worked.

thanks
-Dan

 

[mk]

On Fri, 7 Dec 2007 06:02:34 -0800 (PST), danmc <spam@mcmahill.net>
wrote:

has anyone tried running IC5141 or assura317 under either ubuntu 7.10
or fedora 8? I know they aren't the supported OS's, but it would help
if one of those worked.

thanks
-Dan

IC5141 works nicely on fedora 4 & 7. Haven't installed Fedora 8 yet
but I doubt it will get worse.

 

[Dan]

On Dec 7, 9:09 am, mk <kal*@dspia.*comdelete> wrote:

On Fri, 7 Dec 2007 06:02:34 -0800 (PST), danmc <s...@mcmahill.net
wrote:

has anyone tried running IC5141 or assura317 under either ubuntu 7.10
or fedora 8? I know they aren't the supported OS's, but it would help
if one of those worked.

thanks
-Dan

IC5141 works nicely on fedora 4 & 7. Haven't installed Fedora 8 yet
but I doubt it will get worse.

I am running it on ubuntu 7.10 (fesity) on an amd64 box. ran fine,
until I tried assura317 (libm.so.6 problems with avlck).

 

[andrewb]

On Fri, 7 Dec 2007 12:49:35 -0800 (PST), Dan <dan@e-woodard.net>
wrote:

On Dec 7, 9:09 am, mk <kal*@dspia.*comdelete> wrote:
On Fri, 7 Dec 2007 06:02:34 -0800 (PST), danmc <s...@mcmahill.net
wrote:

has anyone tried running IC5141 or assura317 under either ubuntu 7.10
or fedora 8? I know they aren't the supported OS's, but it would help
if one of those worked.

thanks
-Dan

IC5141 works nicely on fedora 4 & 7. Haven't installed Fedora 8 yet
but I doubt it will get worse.

I am running it on ubuntu 7.10 (fesity) on an amd64 box. ran fine,
until I tried assura317 (libm.so.6 problems with avlck).

The Assura problems are caused by the fact that in the wrapper script
for Assura it sets LD_ASSUME_KERNEL. There's a CCR open for this at
the moment (CCR 509192) - I hit the same problem with RHEL5 (which is
what I have on my laptop now).

In order to get it to work, you should do:

setenv NO_ASSUME_KERNEL " " # anything other than an empty string

I also had to create a script in my installation because it broke
somewhere else - I'm not certain whether this is absolutely necessary.

Anyway, what I did was to create a script:

<assuraInstDir>/share/bin/.cdnWrapper_dev

with the line:

unset LD_ASSUME_KERNEL

Later Linux Kernels really don't like having LD_ASSUME_KERNEL set to
2.4 - applications go horribly wrong as a results (even "ls").

Andrew.

 

[Svenn Are Bjerkem]

On Dec 10, 11:25 am, andrewb <andr...@DcEaLdEeTnEcTe.HcIoSm> wrote:

for Assura it sets LD_ASSUME_KERNEL. There's a CCR open for this at
the moment (CCR 509192) - I hit the same problem with RHEL5 (which is
what I have on my laptop now).

Andrew,
most of us know that the supported version of RHEL can be as old as
RHEL3 for some of the Cadence applications. Problem is not Cadence,
but the rest of the system. RHEL3 is horribly old. For us Linux users
it is horror to have to work with 5 year old versions of a tool just
because our bread and butter application demands it. We do use RHEL4
as rumors tells us that it is ok, but the official roadmap for OS
support is horrible.

Knowing that key application personell at Cadence is using a far to
new version of the OS make me a bit pissed. Why can't the rest of us
also? I want a decent version of python installed, I want the newest
version of vim installed. RHEL does not backport newer versions. I can
compile my own versions, but soon the compiler on RHEL4 is going to be
too old for some of the new tools. Why can't Cadence put some more
effort into upping the support of more modern distributions? You know
what is comming in RHEL if you look carefully at what Fedora is
including. Operating system with built-in crystal ball.
--
Svenn

 

[andrewb]

On Wed, 12 Dec 2007 14:37:40 -0800 (PST), Svenn Are Bjerkem
<svenn.bjerkem@googlemail.com> wrote:

On Dec 10, 11:25 am, andrewb <andr...@DcEaLdEeTnEcTe.HcIoSm> wrote:
for Assura it sets LD_ASSUME_KERNEL. There's a CCR open for this at
the moment (CCR 509192) - I hit the same problem with RHEL5 (which is
what I have on my laptop now).

Andrew,
most of us know that the supported version of RHEL can be as old as
RHEL3 for some of the Cadence applications. Problem is not Cadence,
but the rest of the system. RHEL3 is horribly old. For us Linux users
it is horror to have to work with 5 year old versions of a tool just
because our bread and butter application demands it. We do use RHEL4
as rumors tells us that it is ok, but the official roadmap for OS
support is horrible.

Knowing that key application personell at Cadence is using a far to
new version of the OS make me a bit pissed. Why can't the rest of us
also? I want a decent version of python installed, I want the newest
version of vim installed. RHEL does not backport newer versions. I can
compile my own versions, but soon the compiler on RHEL4 is going to be
too old for some of the new tools. Why can't Cadence put some more
effort into upping the support of more modern distributions? You know
what is comming in RHEL if you look carefully at what Fedora is
including. Operating system with built-in crystal ball.

Actually we do now officially support RHEL4 for IC5141. That changed a
few months ago. It's all to do with the effort of testing.

Cadence has a regular internal platform update which determines the
platform for new releases in a particular period. That sets the OS,
compiler versions, and so on for use in any stream that is released
during that period. Of course, it also defines a minimum release
standard for customers too.

We also have to balance the fact that customers don't want to update
to a new OS all the time, but yet we have to be able to test on a
manageable number of OS versions in a reasonable time. So the version
a tool is built upon is led by the support timeline for that OS,
together with the industry standards for the EDA industry (there's a
link to this on the Cadence web site under platform support).

Now, the fact that I happen to be using RHEL 5 is rather unusual; I'm
rather ahead of the game. Most AEs are using RHEL3 or RHEL4 (in Europe
it's probably mostly RHEL4 - again, that makes sense for newer
releases, and in practice there's not been any compatibility
problems).

My using RHEL5 is partly so that I can take advantage of things like
wireless drivers for my laptop, but also to be aware of any
compatibility problems that customers might hit if they choose to use
either RHEL5 or other unsupported distros based on the same kernel
revision.

So believe me, we are taking the effort - but it's a balance between
the natural conservatism of customers, and practically being able to
test things in a reasonable time with finite resources.

Regards,

Andrew.