Hi Guys,

Not sure if you guys still read this echo but I'm running MBSE 1.0.6 and I
can across a few some minor inconveniences in the compilation process, mainly that
if it doesn't recognise the CPU it naturally doesn't know to call it and what the signal names on that platform are.


So I would say the problems fall under two show-stopping categories:

II. Unnecessary(?) #error's if the CPU is "not one of the above"

In a number of places, the code does a #ifdef to determne the CPU type and whilst I'm impressed by the number of platform supported IBM S/390 and/or z/Series aren't represented (not that I'm surprised, I'm probably the only person in the world running MBSE on any kind of zLinux.

Anyway instead of #error'ing out of the whole compile, I changed the bits
which are CPU sensitive to instead throw a #warn "Unknown CPU, assuming IBM S/390" [of course this should probablysay some differnet].

So from lib/strutil.c:399:2: error: #error "Unknown CPU" I do:

File: lib/strutil.c, starting at line 398>

398: #else
399: #warning "Unknown CPU - defaulting to IBM S/390"
400: return (char *)"IBM S/390";
401: #endif
402: }

I did these/similar changes to these files:

lib/signame.c
lib/strutil.c
mbmon/mbmon.c
mbtask/signame.c

(I just used the signal name array for x86, not ideal but I really didn't
have the time to look up the exact Debian/s390x versions - this shouldn't be too strenuous)

Conclusion
----------

On the plus side, I've been running MBSE 1.0.6 on Debian/s390x for months at
a time without a problem, so nothing too vital seems to be broken.

I would however suggest that you look into those void*<->int casts because
that could break on other platforms as well..
--- SBBSecho 2.27-Win32
* Origin: B4BBS = London = b4bbs.sampsa.com 2:250/7 (2:250/7)

Hello Sampsa!

Saturday October 29 2016 22:35, you wrote to All:

It has been passed to me but my programming intray is still reasonably moderate
to heavy so have not got around to it.

That said I am aware that it does not like CPU's other than the basic and nor for that matter platforms.

In my odd moments have been playing around to get it to work-ish on OSX 10.11 El Capitain) but with minimal effect.

Had to go back to sorting out the code for ACAS for which I have a target for end of the year.

How many CPU's are you running and with what architecture?

Vince

Hi Guys,

Not sure if you guys still read this echo but I'm running MBSE 1.0.6
and I can across a few some minor inconveniences in the compilation
process, mainly that if it doesn't recognise the CPU it naturally
doesn't know to call it and what the signal names on that platform
are.

So I would say the problems fall under two show-stopping categories:

II. Unnecessary(?) #error's if the CPU is "not one of the above"

In a number of places, the code does a #ifdef to determne the CPU type
and whilst I'm impressed by the number of platform supported IBM S/390 and/or z/Series aren't represented (not that I'm surprised, I'm
probably the only person in the world running MBSE on any kind of
zLinux.

Anyway instead of #error'ing out of the whole compile, I changed the
bits which are CPU sensitive to instead throw a #warn "Unknown CPU,
assuming IBM S/390" [of course this should probablysay some
differnet].

So from lib/strutil.c:399:2: error: #error "Unknown CPU" I do:

File: lib/strutil.c, starting at line 398>

398: #else
399: #warning "Unknown CPU - defaulting to IBM S/390"
400: return (char *)"IBM S/390";
401: #endif
402: }

I did these/similar changes to these files:

lib/signame.c
lib/strutil.c
mbmon/mbmon.c
mbtask/signame.c

(I just used the signal name array for x86, not ideal but I really
didn't have the time to look up the exact Debian/s390x versions - this shouldn't be too strenuous)

Conclusion
----------

On the plus side, I've been running MBSE 1.0.6 on Debian/s390x for
months at a time without a problem, so nothing too vital seems to be
broken.

I would however suggest that you look into those void*<->int casts
because that could break on other platforms as well..

Vince

--- Mageia Linux v5/Mbse v1.0.6/GoldED+/LNX 1.1.501-b20150715
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Vince Coen wrote to Sampsa Laine <=-

It has been passed to me but my programming intray is still reasonably moderate
to heavy so have not got around to it.

That said I am aware that it does not like CPU's other than the basic
and nor for that matter platforms.

Vince, like it was discussed on FB, Andrew is taking care of this.

In my odd moments have been playing around to get it to work-ish on OSX 10.11 El Capitain) but with minimal effect.

Had to go back to sorting out the code for ACAS for which I have a
target for end of the year.

Again, I came up with a few suggestions for how to get around the minor annoyances - Andrew's on it.

How many CPU's are you running and with what architecture?

I'm running one emulated Debian/S390x which is basically IBM z/System.

Fun part is that whilst int = 32 bits, pointers are 64 bit.

That's where the (void*) <-> (int) WILL cause crashes. But it's a fairly trivial fix and limited to two minor utilities: MBSE runs fine after some hackery to the files that look for your CPU type and gives up.

Again, nothing time-critical but Andrew's on it.

Sampsa

... MultiMail, the new multi-platform, multi-format offline reader!
--- MultiMail/Darwin v0.49
* Origin: B4BBS = London = b4bbs.sampsa.com 2:250/7 (2:250/7)