• Ticket #9 - Compilation issues on weird platforms..

    From Sampsa Laine@2:250/7 to All on Sat Oct 29 22:35:59 2016
    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)
  • From Vince Coen@2:250/1 to Sampsa Laine on Mon Oct 31 01:52:09 2016
    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)
  • From Sampsa Laine@2:250/7 to Vince Coen on Wed Nov 2 19:36:00 2016
    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)