libevent/tmux for IRIX

[Raion-Fox]

I'd like to see if I can do a port of libevent/tmux to IRIX but unfortunately reimu, my Fuel, is apart for diagnosis and repair.

Does anyone have a system they could let me SSH into for development until I get my system back online? I'll be sure to return the favor. PM me since I want to give us a good alternative to screen.

[Krokodil]

What kind of power do you need to do the development?

[Raion-Fox]

Just a system with both GCC and MIPSPro would be fine and at least 1GB of RAM - and swap space of course in case the disk swaps out. Libevent and tmux aren't exactly that taxing to try and build. I'll ensure I can get them to build, I'll issue any patches and let someone incorporate them into Nekoware.

[Raion-Fox]

Libevent 2.1 stable builds fine with gmake, coreutils, and binutils installed as dependencies. It requires no codepatching.

The problem with tmux is that err.h does not exist on IRIX. Anyone know another header this may be circumvented?

I may be able to build tmux 2.1. Let's try it out.

[miod]

The problem with tmux is that err.h does not exist on IRIX. Anyone know another header this may be circumvented?

Just pick err.h and err.c, errx.c, verr.c, verrx.c, vwarn.c, vwarnx.c, warn.c, warnx.c from any *BSD libc.

[Raion-Fox]

I found the way around it however now it breaks simply because IRIX is unrecognized by the build system - it has support for aix, hpux and solaris but it doesn't know what IRIX has in compat/. Grr. Looks like I'm gonna have to define that all out.

EDIT: The problem is because os-unknown.c doesn't build correctly - the build system doesn't know what fork-pty to do etc. So I'm gonna make a definition for irix in the build system.

[Raion-Fox]

I grabbed NetBSD's err.h, added an ifdef in tmux.c for irix and I found somewhere online a forkpty implementation for irix. I'm gonna see if Krok will let me have access to his Octane again so I can test it further. I hope my hacks to automake/autotools hold up. PITA, it is.

---

GAH I'm foiled at the minute by patch 5329 va_list bug - if you have the patch please PM me immediately.

I have already created ifdefs to fix err.h, hacked configure.ac and patched out the forkpty.c by finding an old forkpty.c online that works okay.

---

Using a series of ill-advised removals of va_list, I was able to bypass the error but now imsg.c wants IOV_MAX and SCM_RIGHTS, neither of which I think exist on IRIX... help?

[miod]

Using a series of ill-advised removals of va_list, I was able to bypass the error but now imsg.c wants IOV_MAX and SCM_RIGHTS, neither of which I think exist on IRIX... help?

Be sure to compile with _XOPEN_SOURCE defined (to get SCM_RIGHTS among other things), and use _XOPEN_IOV_MAX for IOV_MAX.

[Raion-Fox]

Gotcha I'll add ifdefs for that

---

Okay so I added an ifdef to imsg.c, imsg.h & imsg-buffer.c

#if defined(irix) || defined (__irix__) || defined(sgi) || defined (__sgi__)
#define _XOPEN_IOV_MAX 16
#define _XOPEN_SOURCE 4
#endif

Worked somewhat well. Now I've got issues with imsg-buffer.c

Ugh I give up for the present. I need to get FoxBSD Alpha 1 Faye Valentine released. In the meantime, I'll drop the patched code here. I removed err.h and the compiler allows implicit declaration even though that's a warning. This is NOT my best work by far, it's probably some of the worst code I've pushed. forkpty-unknown.c is not my work at all but some random old code I found online in the sourceforge repo. It's hacked together, its nasty and it's probably broken in a few places.

[spiroyster]

Implicit declaration? function will be assumed to return an int, so better hope it does

Which compiler are you using for this? If gcc, it's recommended to compile with '-Werror' or enforce later standards. This isn't a compliers problem, more a linkers problem, hence it's a compiler warning. This is in fact old standard for a compiler to let this slip, and can lead to problematic code at run time (if linker lets it pass) which is why later standards (C99) prohibit this.

If you know the signature of the function you are calling (o.0),I can't see a reason not to prototype it?

Also, are _XOPEN_IOV_MAX and _XOPEN_SOURCE pre defined to different values? if so advisable to #undef before defining them.

[Raion-Fox]

Implicit declaration? function will be assumed to return an int, so better hope it does

I was having issues with u_char so I typdef'd it as unsig

Which compiler are you using for this? If gcc, it's recommended to compile with '-Werror' or enforce later standards. This isn't a compliers problem, more a linkers problem, hence it's a compiler warning. This is in fact old standard for a compiler to let this slip, and can lead to problematic code at run time (if linker lets it pass) which is why later standards (C99) prohibit this.

The place where I got stuck was the struct ibuf in imsg.h being declared by the code not picking it up. I was using GCC 4.7. I was gonna run them with GCC first, and then try making them run under MIPSPro if there was performance benefits.

Also, are _XOPEN_IOV_MAX and _XOPEN_SOURCE pre defined to different values? if so advisable to #undef before defining them.

I don't know. I googled people who added their definitions in, checked their code and used the values there.

Here's the issue - I consider myself an amateur at C, especially when it is code that I didn't write. Now for FoxBSD, most of what I've been doing is patch integration, changes to default configs and removal of buildsystem pieces from make. I have not a lot of experience with IRIX's buildsystem.

building tmux requires automake and autotools to be installed, for autogen.sh, gmake, GCC 4.7 and the usual nekoware flags to be thrown. I'm done for the time being with this project. I have ordered a Challenge S on eBay as well as an O300, both of which will be patched and setup better for development on IRIX.

[kev009]

Hah, I did the Irix fixes for libevent 2.x upstream many moons ago.

[Raion-Fox]

Yeah Libevent compiles great even under MIPSPro. But with tmux it just... doesn't fucking work.

[dexter1]

From http://tmux-users.narkive.com/1rppDdhM/irix-support :

2010-02-10 19:08:19 UTC
I had an IRIX shell but the tmux support didn't work and I didn't have time to finish it.

Hi,
I see that previous versions up to tmux-0.8 had limited support for IRIX but since then, the support has been dropped. Is there technical reasons or just no hardware available?

This doesn't give me much hope of tmux ever supporting IRIX, but i went ahead and tried to compile it with MIPSPro 7.4.4 (IRIX 6.5.30 + patches).
So I have created a patchfile which i included as attachment. Used libevent 2.1.8 and plain SGI curses. This apparently satisfies tmux configure command.

The main problems are osdep-irix.c for which i copied the osdep-hpux.c , but it is basically an empty placeholder.
forkpty-irix.c is interestingly from an older tmux/compat folder, probably early 1.2 version or something in that range.

Code: Select all

setenv MAKE /usr/nekoware/bin/gmake
setenv CC c99
setenv CFLAGS '-O2 -mips4 -I/usr/local/include'
setenv LDFLAGS '-L/usr/local/lib'

This should be a good env to compile with.

Using a series of ill-advised removals of va_list, I was able to bypass the error but now imsg.c wants IOV_MAX and SCM_RIGHTS, neither of which I think exist on IRIX... help?

Be sure to compile with _XOPEN_SOURCE defined (to get SCM_RIGHTS among other things), and use _XOPEN_IOV_MAX for IOV_MAX.

i tried _XOPEN_SOURCE with and without _XOPEN_SOURCE_EXTENDED but i got u_char definitions getting dropped from the code.
It's not that critical however: SCM_RIGHTS is a static 0x01 and IOV_MAX is actually a sysconf parameter which you can interrogate using

Code: Select all

sysconf IOV_MAX

or dynamically with

Code: Select all

sysconf(_SC_IOV_MAX)

I didn't see the err.h problem, but that is probably because i did not compile openssl support into libevent: Actually, err.h lives in /usr/nekoware/include/openssl/err.h

This gives me a binary tmux, but it refuses to run:

Code: Select all

mech002:/usr/people/feverdij/src/tmux-2.5> ldd tmux
        libxnet.so  =>   /usr/lib32/libxnet.so 
        libevent-2.1.so.7  =>    /usr/local/lib/libevent-2.1.so.7       
        libcurses.so  =>         /usr/lib32/libcurses.so       
        libgen.so  =>    /usr/lib32/libgen.so   
        libc.so.1  =>    /usr/lib32/libc.so.1
mech002:/usr/people/feverdij/src/tmux-2.5> ./tmux
tmux: need UTF-8 locale (LC_CTYPE) but have ISO8859-1
mech002:/usr/people/feverdij/src/tmux-2.5> setenv LC_CTYPE ISO8859-1
mech002:/usr/people/feverdij/src/tmux-2.5> ./tmux
tmux: invalid LC_ALL, LC_CTYPE or LANG

It looks like UTF-8 is hardcoded, which i'm surprised about. Didn't we use to have libintl/libiconv for this to have proper localization in code? It seems odd to not include such a compatibility layer into a program. We need other charset supported in tmux if we are going to use it in IRIX shells.

The most tedious problem i encountered in the code are coming from anonymous unions and structs. It is not supported in C99 but is a gnu extension, which has found its way in C11 standard. You'll get warning messages like:

Code: Select all

cc-1040 c99: WARNING File = tmux.h, Line = 557
  An identifier is expected.

        };

...which subsequently breaks code compiles with such an anonymous union:

Code: Select all

cc-1565 c99: ERROR File = grid.c, Line = 69
  The struct "grid_cell_entry" has no field "data".

        gce->data.fg = gc->fg & 0xff;

The best, although laborious option, is to un-anonymize the unions and structs. It is sufficient to add an identifier:

Code: Select all

struct grid_cell_entry {
   u_char         flags;
   union {
      u_int      offset;
      struct {
         u_char   attr;
         u_char   fg;
         u_char   bg;
         u_char   data;
      } data;
   } u;     <----- un-anonymize
} __packed;


... and then change all struct and union access to use the new identifier.

Anyway, have a look at my work. If you have time to do a functional IRIX port, it will need old code from tmux-1.x and some locale internationalization support with gnu gettext/libiconv which is ported via nekoware. But that might be a lot of work.

[Raion-Fox]

Finally got a chance to look at the code. Very good, to have gotten this far. Implementing patches to fix the charset support is probably not going to be worth it - I'm tabling this indefinitely. I'm gonna try byobu next, to see if that works well. I've got other stuff in the pipe but I'm currently dealing with most of my machines being in storage while I try to move from my house which is literally falling apart (the rainy summer has ruined the rear section of the roof and put a hole in my ceiling as wide as Joe Pesci)