By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,885 Members | 1,469 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,885 IT Pros & Developers. It's quick & easy.

Problem with frozen app: compatibility between Unixware and SCO Unix

P: n/a
I need to deploy a Python app on both SCO Unixware and old SCO Unix
boxes. We freeze the app under Unixware, and set the compatibility
flag ('elfmark -t udk') on the resulting executable. We successfully
did this using Python 1.5.2. Recently, we decided to upgrade the app
to use Python 2.3.2.

Unfortunately, we've just discovered a nasty surprise. Under 2.3.2,
os.path.isdir() returns True on Unixware for an existing directory
(/tmp, for example), but returns False under SCO Unix. Ouch.

Note that this has been verified using a test program that is frozen
under Unixware, then run on Unixware and SCO Unix. We don't currently
have a python interpreter on the SCO Unix box.

Because of the way a frozen app is involved, I'm thinking that this is
a binary compatibility problem, and will investigate further. We do
the same 'compile under Unixware, deploy under SCO Unix' thing for
many other apps that are written in C, without encountering this
problem.

Does anyone have any suggestions on how I can best proceed? Have you
heard of this kind of problem before? What additional information
would you like to read?

Thanks
Jul 18 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Mike Kent <mk***@webmd.net> pisze:
What additional information would you like to read?


Why you still work with this piece of shit?

BP, NMSP ("I'm Sorry, I Couldn't Resist")

--
Jarek Zgoda
Unregistered Linux User #-1
http://www.zgoda.biz/ JID:zg***@chrome.pl http://zgoda.jogger.pl/
Jul 18 '05 #2

P: n/a
Upon further intense investigation, here's what I now know.

os.stat() is the culprit. A very simple test program frozen under
Unixware 7.1 which does more more than stat '/tmp' will return proper
results under Unixware, but return totally bogus results when that
frozen test program is run on an OpenServer 5 machine. Bogus in the
sense that the tuple of values returned by os.stat() contain values
that are so far off, it is apparent that the structure returned by the
OS's 'stat' system call is not being unpacked properly.

The docs for the Unixware UDK state that the 'stat' system call is
fully compatible across the two platforms. This was verified by
writing a short 'C' language program, compiling it under Unixware, and
running it on both Unixware and OpenServer. In both cases, it
returned proper results.

The problem appears to be something in Python's wrapper around 'stat'
in posixmodule.c

Any ideas on how I can proceed?
Jul 18 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.