L1101, L1209 from link386 - OS2

This is a discussion on L1101, L1209 from link386 - OS2 ; I'm testing the latest gcc[*], used with EMX CRTL. The non-debugging build finishes fine (with 2 bugs visible in the application, and __alloca() quickly implemented in assembler). However, when I try a debugging build, I get major problems with link386. ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: L1101, L1209 from link386

  1. L1101, L1209 from link386

    I'm testing the latest gcc[*], used with EMX CRTL. The non-debugging
    build finishes fine (with 2 bugs visible in the application, and
    __alloca() quickly implemented in assembler). However, when I try a
    debugging build, I get major problems with link386.
    [*] as-2.14-os2-20081015.zip, gcc-4.3.2-os2-20081014.zip (google groups)

    Depending on how I sort the .obj files, I get one of

    gp_init.obj(..\src\gp\gp_init.c) : fatal error L1101: invalid object module
    Object file offset: 2bcf Record type: 9d

    or

    Qfb.obj(..\src\basemath\Qfb.c) : fatal error L1209:

    I suspect that L1101 is bogus, and the main reason is running out of
    memory. Are there any workarounds?

    The library is quite small, about 5MB (compiled with debugging info),
    and about 2500 entry points...

    Thanks,
    Ilya

    P.S. Just in case, the command line is (with EMX's gcc)

    gcc.exe -Zomf -Zcrtdll -Zstack 8192 -o gp-sta -DMEMSTEP=1048576 -g -Wall -Zmt -Zexe mp.obj mpinl.obj Flx.obj Qfb.obj RgX.obj alglin1.obj alglin2.obj arith1.obj arith2.obj base1.obj base2.obj base3.obj base4.obj base5.obj bibli1.obj bibli2.obj buch1.obj buch2.obj buch3.obj buch4.obj galconj.obj gen1.obj gen2.obj gen3.obj ifactor1.obj perm.obj polarit1.obj polarit2.obj polarit3.obj rootpol.obj subcyclo.obj subgroup.obj trans1.obj trans2.obj trans3.obj anal.obj compat.obj default.obj errmsg.obj es.obj i
    nit.obj intnum.obj members.obj sumiter.obj aprcl.obj elldata.obj elliptic.obj galois.obj groupid.obj kummer.obj mpqs.obj nffactor.obj part.obj stark.obj subfield.obj thue.obj os2.obj gp.obj gp_rl.obj highlvl.obj whatnow.obj plotport.obj plotnull.obj gp_init.obj -lreadline_import -lm

  2. Re: L1101, L1209 from link386

    On 10/15/08 09:14 pm, Ilya Zakharevich wrote:
    > I'm testing the latest gcc[*], used with EMX CRTL. The non-debugging
    > build finishes fine (with 2 bugs visible in the application, and
    > __alloca() quickly implemented in assembler). However, when I try a
    > debugging build, I get major problems with link386.
    >
    >[*] as-2.14-os2-20081015.zip, gcc-4.3.2-os2-20081014.zip (google groups)
    >
    > Depending on how I sort the .obj files, I get one of
    >
    > gp_init.obj(..\src\gp\gp_init.c) : fatal error L1101: invalid object module
    > Object file offset: 2bcf Record type: 9d
    >
    > or
    >
    > Qfb.obj(..\src\basemath\Qfb.c) : fatal error L1209:
    >
    > I suspect that L1101 is bogus, and the main reason is running out of
    > memory. Are there any workarounds?
    >
    > The library is quite small, about 5MB (compiled with debugging info),
    > and about 2500 entry points...
    >
    > Thanks,
    > Ilya
    >
    > P.S. Just in case, the command line is (with EMX's gcc)
    >
    > gcc.exe -Zomf -Zcrtdll -Zstack 8192 -o gp-sta -DMEMSTEP=1048576 -g -Wall -Zmt -Zexe mp.obj mpinl.obj Flx.obj Qfb.obj RgX.obj alglin1.obj alglin2.obj arith1.obj arith2.obj base1.obj base2.obj base3.obj base4.obj base5.obj bibli1.obj bibli2.obj buch1.obj buch2.obj buch3.obj buch4.obj galconj.obj gen1.obj gen2.obj gen3.obj ifactor1.obj perm.obj polarit1.obj polarit2.obj polarit3.obj rootpol.obj subcyclo.obj subgroup.obj trans1.obj trans2.obj trans3.obj anal.obj compat.obj default.obj errmsg.obj es.obj i
    > nit.obj intnum.obj members.obj sumiter.obj aprcl.obj elldata.obj elliptic.obj galois.obj groupid.obj kummer.obj mpqs.obj nffactor.obj part.obj stark.obj subfield.obj thue.obj os2.obj gp.obj gp_rl.obj highlvl.obj whatnow.obj plotport.obj plotnull.obj gp_init.obj -lreadline_import -lm


    Well the first thing to try is using ilink (or wlink) instead of
    link386. (ftp://ftp.software.ibm.com/ps/produc...la/ilink50.zip,
    or wlink from 1.6 or newer. Note you need to set a couple of environment
    variables for wlink).
    Also note that wlink is only licensed for building Mozilla. I doubt
    anyone will care though.
    Dave

  3. Re: L1101, L1209 from link386

    [A complimentary Cc of this posting was sent to
    Dave Yeo
    ], who wrote in article :
    > Well the first thing to try is using ilink (or wlink) instead of
    > link386. (ftp://ftp.software.ibm.com/ps/produc...la/ilink50.zip,


    Thanks. I see that one needs to use /nofree option to make the syntax
    compatible. So do I need to rename ilink to link386, put its
    directory to PATH, and use -O/nofree on emxomfld command line, right?
    And control from gcc line, I need -Xlinker -O/nofree (or the
    abomination -Wl,-O/nofree ?), right?

    Looks doable... [I suspect after-EM's linkers have simpler ways to
    substitute linker executable, but for a moment I want to upgrade
    piecemeal...]

    > or wlink from 1.6 or newer. Note you need to set a couple of environment
    > variables for wlink).


    Is it a Watcom linker, or what? Where, and how?

    > Also note that wlink is only licensed for building Mozilla. I doubt
    > anyone will care though.


    Hmm, is not all Watcom opensourced?

    Thanks again,
    Ilya




  4. Re: L1101, L1209 from link386

    [A complimentary Cc of this posting was NOT [per weedlist] sent to
    Ilya Zakharevich
    ], who wrote in article :
    > [A complimentary Cc of this posting was NOT [per weedlist] sent to
    > Dave Yeo
    > ], who wrote in article :
    > > Well the first thing to try is using ilink (or wlink) instead of
    > > link386. (ftp://ftp.software.ibm.com/ps/produc...la/ilink50.zip,

    >
    > Thanks. I see that one needs to use /nofree option to make the syntax
    > compatible. So do I need to rename ilink to link386, put its
    > directory to PATH, and use -O/nofree on emxomfld command line, right?
    > And control from gcc line, I need -Xlinker -O/nofree (or the
    > abomination -Wl,-O/nofree ?), right?
    >
    > Looks doable... [I suspect after-EM's linkers have simpler ways to
    > substitute linker executable, but for a moment I want to upgrade
    > piecemeal...]


    No, I could not convince it to work. As a result, I needed to
    download Holger's version from
    http://crydee.sai.msu.ru/ftproot/pub...r/emxomfld.exe
    And, one must keep in mind that (by default?) gcc will use emxomfld
    from the EMX/BIN directory. I could not find a way to overwrite the
    directory (or name) of emxomfld...

    [While doing this, I also applied my old patch to emit ALL the info
    about invocation of the linker when -i is given to emxomfld.
    Turned out that `gcc -v' would be quite enough to uncover the
    problems I saw, but anyway...]

    Now I have the debugging compile, and, of course, it shows no bug.
    ;-) Need to recompile again...

    Thanks,
    Ilya

  5. Re: L1101, L1209 from link386

    Ilya Zakharevich wrote:
    > I'm testing the latest gcc[*], used with EMX CRTL. The non-debugging
    > build finishes fine (with 2 bugs visible in the application, and
    > __alloca() quickly implemented in assembler). However, when I try a
    > debugging build, I get major problems with link386.
    >
    >[*] as-2.14-os2-20081015.zip, gcc-4.3.2-os2-20081014.zip (google groups)
    >
    > Depending on how I sort the .obj files, I get one of
    >
    > gp_init.obj(..\src\gp\gp_init.c) : fatal error L1101: invalid object module
    > Object file offset: 2bcf Record type: 9d
    >
    > or
    >
    > Qfb.obj(..\src\basemath\Qfb.c) : fatal error L1209:
    >
    > I suspect that L1101 is bogus, and the main reason is running out of
    > memory. Are there any workarounds?
    >
    > The library is quite small, about 5MB (compiled with debugging info),
    > and about 2500 entry points...
    >
    > Thanks,
    > Ilya
    >
    > P.S. Just in case, the command line is (with EMX's gcc)
    >
    > gcc.exe -Zomf -Zcrtdll -Zstack 8192 -o gp-sta -DMEMSTEP=1048576 -g -Wall -Zmt -Zexe mp.obj mpinl.obj Flx.obj Qfb.obj RgX.obj alglin1.obj alglin2.obj arith1.obj arith2.obj base1.obj base2.obj base3.obj base4.obj base5.obj bibli1.obj bibli2.obj buch1.obj buch2.obj buch3.obj buch4.obj galconj.obj gen1.obj gen2.obj gen3.obj ifactor1.obj perm.obj polarit1.obj polarit2.obj polarit3.obj rootpol.obj subcyclo.obj subgroup.obj trans1.obj trans2.obj trans3.obj anal.obj compat.obj default.obj errmsg.obj es.obj i
    > nit.obj intnum.obj members.obj sumiter.obj aprcl.obj elldata.obj elliptic.obj galois.obj groupid.obj kummer.obj mpqs.obj nffactor.obj part.obj stark.obj subfield.obj thue.obj os2.obj gp.obj gp_rl.obj highlvl.obj whatnow.obj plotport.obj plotnull.obj gp_init.obj -lreadline_import -lm


    Wow. I just did a double-take on 5MB being called "quite small." OTOH,
    Link386 should be able to handle it. Why not get a copy of "dmpobj"
    from the Intel tis site and see what it's complaining about?

    --
    prf

  6. Re: L1101, L1209 from link386

    On 10/16/08 01:40 am, Ilya Zakharevich wrote:
    > [A complimentary Cc of this posting was sent to
    > Dave Yeo
    > ], who wrote in article:
    >> Well the first thing to try is using ilink (or wlink) instead of
    >> link386. (ftp://ftp.software.ibm.com/ps/produc...la/ilink50.zip,

    >
    > Thanks. I see that one needs to use /nofree option to make the syntax
    > compatible. So do I need to rename ilink to link386, put its
    > directory to PATH, and use -O/nofree on emxomfld command line, right?
    > And control from gcc line, I need -Xlinker -O/nofree (or the
    > abomination -Wl,-O/nofree ?), right?


    The bottom of this page explains the environment variables for various
    linkers. With ilink 5.0 linking should just work.
    There is also a version of wlink (wl.exe) at netlabs.org in the gcc
    directory that has been patched for the right debug output that also
    works fine for me after setting the right variables.

    >
    > Looks doable... [I suspect after-EM's linkers have simpler ways to
    > substitute linker executable, but for a moment I want to upgrade
    > piecemeal...]
    >
    >> or wlink from 1.6 or newer. Note you need to set a couple of environment
    >> variables for wlink).

    >
    > Is it a Watcom linker, or what? Where, and how?


    Yes it is the Watcom linker, the only one we have source for. Note IIRC
    wlink has to be from OpenWatcom 1.6 or newer.

    >
    >> Also note that wlink is only licensed for building Mozilla. I doubt
    >> anyone will care though.

    >
    > Hmm, is not all Watcom opensourced?


    Sorry, typo. I meant ilink.

    >
    > Thanks again,
    > Ilya


    Dave

  7. Re: L1101, L1209 from link386

    [A complimentary Cc of this posting was sent to
    Dave Yeo
    ], who wrote in article :
    > >> Well the first thing to try is using ilink (or wlink) instead of
    > >> link386. (ftp://ftp.software.ibm.com/ps/produc...la/ilink50.zip,


    > > Thanks. I see that one needs to use /nofree option to make the syntax
    > > compatible. So do I need to rename ilink to link386, put its
    > > directory to PATH, and use -O/nofree on emxomfld command line, right?
    > > And control from gcc line, I need -Xlinker -O/nofree (or the
    > > abomination -Wl,-O/nofree ?), right?


    > The bottom of this page explains the environment variables for various
    > linkers. With ilink 5.0 linking should just work.


    Is not the first sentence somewhat incomplete?

    > >> Also note that wlink is only licensed for building Mozilla. I doubt
    > >> anyone will care though.


    > > Hmm, is not all Watcom opensourced?


    > Sorry, typo. I meant ilink.


    I looked in the FTP directory, and in ilink.html, and all I see is

    The licensed program described in this document and all licensed
    material available for it are provided by IBM under terms of the IBM
    Customer Agreement, IBM International Program License Agreement, or
    any equivalent agreement between us.

    Puzzled,
    Ilya

  8. Re: L1101, L1209 from link386

    [A complimentary Cc of this posting was sent to
    Peter Flass
    ], who wrote in article :
    > > Depending on how I sort the .obj files, I get one of
    > >
    > > gp_init.obj(..\src\gp\gp_init.c) : fatal error L1101: invalid object module
    > > Object file offset: 2bcf Record type: 9d
    > >
    > > or
    > >
    > > Qfb.obj(..\src\basemath\Qfb.c) : fatal error L1209:
    > >
    > > I suspect that L1101 is bogus, and the main reason is running out of
    > > memory. Are there any workarounds?


    > Link386 should be able to handle it. Why not get a copy of "dmpobj"
    > from the Intel tis site and see what it's complaining about?


    Sorry, I forgot to expand that L1209 is "running out of some memory
    pool". Given that ilink links it without any complaint, and the
    result passes the (smallish) test suite, I STILL think ;-) that L1101
    was bogus...

    Thanks,
    Ilya

  9. Re: L1101, L1209 from link386

    On 10/16/08 01:19 pm, Ilya Zakharevich wrote:
    >> The bottom of this page explains the environment variables for various
    >> > linkers. With ilink 5.0 linking should just work.

    >
    > Is not the first sentence somewhat incomplete?


    Sorry, I shouldn't post when getting ready for work The URL is
    http://svn.netlabs.org/libc/wiki/kOptions

    >
    >>>> > >> Also note that wlink is only licensed for building Mozilla. I doubt
    >>>> > >> anyone will care though.

    >
    >>> > > Hmm, is not all Watcom opensourced?

    >
    >> > Sorry, typo. I meant ilink.

    >
    > I looked in the FTP directory, and in ilink.html, and all I see is
    >
    > The licensed program described in this document and all licensed
    > material available for it are provided by IBM under terms of the IBM
    > Customer Agreement, IBM International Program License Agreement, or
    > any equivalent agreement between us.
    >


    Perhaps I misremembered or they have changed their license.
    Dave

+ Reply to Thread