32/64-bit portabliity

[Stephen Keane]

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?

[A. Clay Stephenson]

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).

[Stephen Keane]

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

[Arunvijai_4]

Hi stephen,

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

-Arun

[A. Clay Stephenson]

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.

[Steven E. Protter]

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

[Stephen Keane]

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.

[Stephen Keane]

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?

[Dennis Handly]

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

[A. Clay Stephenson]

---- 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.

[Stephen Keane]

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.

[Stephen Keane]

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.

[Stephen Keane]

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?

[A. Clay Stephenson]

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.

[Stephen Keane]

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?

[A. Clay Stephenson]

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.

[Stephen Keane]

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!

[A. Clay Stephenson]

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.

[Stephen Keane]

(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?

[A. Clay Stephenson]

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.

[Stephen Keane]

Unfortunately, I can't change the terminfo database on the target machine (it isn't my machine). I'm attempting to get a copy of it to copy onto my machine to see if I can replicate the problem locally.

The application is statically linked with the ncurses archive libraries. There are no ncurses shared libraries on the target machine. Also, perhaps more importantly, there are no ncurses binaries on the target machine, it uses the HP supplied variants of clear/infocmp/tic/toe/tput/tset etc. so the target machine has HP terminfo databases and HP term habdling binaries.

I've been experimenting with setting TERMINFO and TERMCAP, but it doesn't seem to make any difference.

[Stephen Keane]

Oh and tic and infocmp both work OK.

[Stephen Keane]

OK, I recompiled the ncurses sources with --disable-termcap and ran the application.

If TERMINFO is not set, you get an error message. If TERMINFO is set (correctly) the application works fine.

Just to check, I then recompiled the ncurses sources without --disable-termcap and ran the application.

If TERMINFO is not set you don't (now) get a core-dump, you get an error message about "Name collision between h hh" etc. IF TERMINFO is set (correctly) the application works fine.

So unless the orginal ncurses build was somehow corrupted, I don't get it. But I have an application that works and I'm seeing if it works on the 32-bit version of 11.00 too.