topic Re: 32/64-bit portabliity in Operating System - Linux

32/64-bit portabliity

Stephen Keane — Wed, 21 Jun 2006 11:03:34 GMT

I have some code that was written and comliled (using gcc) on HP-UX 11.00 with a 64-bit O/S. It is PARISC1.1.

When I try and run it on a HP-UX 11.00 box with 32-bit O/S anything using curses fails (coredump SIGSEGV). But anything not using curses works OK.

All the libraries I have used/linked are PARISC1.1

Any clues?

Re: 32/64-bit portabliity

A. Clay Stephenson — Wed, 21 Jun 2006 11:17:53 GMT

You know the drill. Anything w/o a stack trace is using "The Force". Since you mentioned gcc, is it possible the problem is actually minor differences in "real" curses and ncurses? I simply haven't used gcc enough on HP-UX to know much about this but the HP C compilers handle this easily as long as the overrides are in place so that the compiler does not choose the native type of the machine that the compiler happens to reside on. I have seen cases where problems like you describe were compiled and dynamically linked to "real" curses on the original machine and failed when linked against ncurses on the target machine (although the dynamic linking itself succeeded).

Re: 32/64-bit portabliity

Stephen Keane — Wed, 21 Jun 2006 11:20:20 GMT

I've statically linked the ncurses libraries on the build machine, there are no ncurses libraries on the target machine.

Re: 32/64-bit portabliity

Arunvijai_4 — Wed, 21 Jun 2006 12:03:01 GMT

Hi stephen,

Did you compile with ncurses of 64 bit (PA-RISC1.1) ? Jus a thought i should say ..

-Arun

Re: 32/64-bit portabliity

A. Clay Stephenson — Wed, 21 Jun 2006 12:09:04 GMT

That would not link. I suspect what you are going to have to do is download the ncurses source, compile it with -g to include the debugger information, and compile your application also with -g and let it crash and then do a stack trace. However, it probably will run perfectly at this point because -g implies no optimizer -- and because you have now compiled the ncurses library on your machine.

The other thing that might cause problems is that if ncurses were compiled with one set of header files and your application were compiled with another slightly different set of header files.

Re: 32/64-bit portabliity

Steven E. Protter — Wed, 21 Jun 2006 12:09:56 GMT

Shalom Stephen,

You need to recompile for higher platforms.

Once you do that, you should be able to maintain 32 and 64 bit versions. I'm told 11 v2's 32 bit emulation solves a lot of problems when compared to other earlier OS versions.

SEP

Re: 32/64-bit portabliity

Stephen Keane — Thu, 22 Jun 2006 08:49:39 GMT

OK, I don't have access to the 11.00 32-bit kernel box. What I have is a 11.00 64 bit kernel box. What I have done i download ncurses 5.5 source and comiled it on the 11.00 64-bit kernel box and statically linked it into the application. Then sent the application to the client. Hopefully, the client will be able to try and run the application and tell me waht happened (eventually). Nothing like trying to develop on a box you don't have.

Re: 32/64-bit portabliity

Stephen Keane — Tue, 27 Jun 2006 10:18:26 GMT

I've now completely recompiled everything (including ncurses) on a 64-bit HP-UX 11.00 machine and statically linked the ncurses ".a" libraries into the executable. But if you run it on a 32-bit HP-UX 11.00 machine, it core dumps (SEGV). If I try the same thing using an application that doesn't use ncurses, then it works OK. This leads me to suspect that it is the ncurses that is causing the problem.

Does anyone have ncurses running successfully on 32-bit HP-UX 11.00, and if so

(a) what version of ncurses is it and

(b) where did they get it from please?

Re: 32/64-bit portabliity

Dennis Handly — Tue, 27 Jun 2006 20:03:14 GMT

As Clay suggesteded, what is the stack trace? That may point to something that isn't ncurses.

Re: 32/64-bit portabliity

A. Clay Stephenson — Tue, 27 Jun 2006 20:52:24 GMT

---- and don't overlook that although ncurses seems to be the chief suspect, the real criminal may be a routine that ncurses calls that is dynamically linked -- perhaps to something in libc. I haven't heard you state that the application is completely statically linked. In lieu of "The Force", a stack trace would seem to be helpful.

Re: 32/64-bit portabliity

Stephen Keane — Wed, 28 Jun 2006 04:02:27 GMT

Only the ncurses libraries are statically linked. The other libraries used are dynamically linked.

/usr/lib/libc.2
/usr/lib/libdld.2
/usr/lib/libm.2
/usr/local/lib/libstdc++.sl

I'll see if I can get hold of a stack trace, as I feel a weakness in the force.

Re: 32/64-bit portabliity

Stephen Keane — Fri, 30 Jun 2006 03:18:13 GMT

It gets weirder. I have compiled on a 64-bit 11.00 box (B1000) and it won't run on another 64-bit 11.00 box (D390). Anything using ncurses core dumps, even though the ncurses libraries were statically linked, anything not using ncurses is fine.

Re: 32/64-bit portabliity

Stephen Keane — Fri, 30 Jun 2006 15:51:37 GMT

Finally got a stack trace

#0 0x0004702c in postprocess_termcap ()
#1 0x00046678 in _nc_parse_entry ()
#2 0x0003fd68 in _nc_read_entry_source ()
#3 0x0003b6b8 in _nc_read_termcap_entry ()
#4 0x0002baf0 in grab_entry ()
#5 0x0002bfd0 in _nc_setupterm ()
#6 0x0002c1c8 in setupterm ()
#7 0x00030ae4 in newterm ()
#8 0x00025380 in initscr ()
Cannot access memory at address 0xffffea6d

Definitely the ncurses5.5 library that is core-dumping then.

Why is it using a termcap function, I though ncurses preferred terminfo entries?

Re: 32/64-bit portabliity

A. Clay Stephenson — Fri, 30 Jun 2006 16:18:19 GMT

That is one of the options when ncurses is build. Configure can build a makefile that causes curses to fallback on termcap when a terminfo for a particular TERM is not found. You can also build it to use terminfo only -- or termcap only.

Actually they may be a few cases where termcap makes sense because unlike terminfo, terminfo can deal with completely ad hoc capability names that you make up yourself. The terminfo compiler would choke on a madeup capability name.

I suspect that you may be running on boxes which do not have matching terminfo entries but do have matching termcap entries and the fallback is what is killing you and why it works on some boxes and doesn't on others. The OS "bitness" probably has nothing to do with it.

Amazingly now that I have a stack trace, "The Force" seems stronger.

Re: 32/64-bit portabliity

Stephen Keane — Fri, 30 Jun 2006 16:27:16 GMT

Now that the force is stronger, any ideas on how to proceed?

I have TERM=vt100
I have TERMINFO=/usr/share/terminfo

I have /usr/local/share/terminfo/v/vt100
I have /usr/share/lib/terminfo/v/vt100

I have also tried TERM=vt220, TERM=hp etc.

How do I configure ncurses to not use TERMCAP for instance?

Re: 32/64-bit portabliity

A. Clay Stephenson — Fri, 30 Jun 2006 16:47:24 GMT

Run configure -h to list the build options for configure but I think it is --disable-termcap. I only run ncurses on Linux and even there I had to fix a problem with signal handling as ncurses was causing SIGINT's to be ignored eventhough a signal handler was in place.

Also make sure that your application code isn't being compiled with one set of header files and ncurses another so that structs are slightly different.

Re: 32/64-bit portabliity

Stephen Keane — Fri, 30 Jun 2006 16:55:52 GMT

I've just rebuilt the ncurses using --disable-termcap (good guess by the way). I am rebuilding the application and will try it on the "problem" server.

Presumably the ncurses library will throw an error if it can't find a suitable terminfo, as I've asked it not to fall-back on termcap?

I'm also getting a copy of the terminfo files from the "problem" server to see if I can "break" my system by using them. If I could only get it to break here, I'd be one step closer to fixing it!

Re: 32/64-bit portabliity

A. Clay Stephenson — Fri, 30 Jun 2006 17:14:43 GMT

While you are building, I would build with -g so that you get the full debugger info in the objects --- that should make finding Darth Curses rather easy.

Re: 32/64-bit portabliity

Stephen Keane — Sat, 01 Jul 2006 08:11:44 GMT

(Partial) success. The rebuilt ncurses doesn't core-dump (I rebuilt it to not use termcap). Instead it says error opening termianl, when TERM is set to "vt100", "vt220", "xterm" etc. There do appear to be terminfo definitions for all of these terminal types, so I rebuild the ncurses library with debugging symbols termcap enabled and try to see why (specifically) core-dumps. I also need to find out why it can't use the terminfo database.

Is there a quick way to verify the terminfo database files?

Re: 32/64-bit portabliity

A. Clay Stephenson — Sat, 01 Jul 2006 21:10:15 GMT

Generally you can run "untic vt200 > vt200.txt" or "infocmp vt200 > vt200.txt" to "uncompile" the binary. I'm betting that if you tic (using the ncurses version) then your problems will be fixed. Off the top of my head, ncurses expects the terminfo library to be under /usr/local/lib rather than the traditional /usr/lib.