• Menu reference to nonexistent node error

    From Khusraw@21:1/5 to All on Tue Feb 22 10:28:29 2022
    When I try to build DJGPP from CVS I get the following errors:

    libc.tex:134: Menu reference to nonexistent node `waitpid' (perhaps incorrect sectioning?).
    libc.tex:133: Menu reference to nonexistent node `wait' (perhaps incorrect sectioning?).
    libc.tex:132: Menu reference to nonexistent node `vfork' (perhaps incorrect sectioning?)
    libc.tex:131: Menu reference to nonexistent node `umask' (perhaps incorrect sectioning?)
    libc.tex:130: Menu reference to nonexistent node `tcsetpgrp' (perhaps incorrect sectioni
    libc.tex:129: Menu reference to nonexistent node `tcsendbreak' (perhaps incorrect sectio
    libc.tex:128: Menu reference to nonexistent node `tcdrain' (perhaps incorrect sectioning
    libc.tex:127: Menu reference to nonexistent node `setuid' (perhaps incorrect sectioning?).
    libc.tex:126: Menu reference to nonexistent node `setsid' (perhaps incorrect sectioning?).
    libc.tex:125: Menu reference to nonexistent node `setpgid' (perhaps incorrect sectioning?).
    libc.tex:124: Menu reference to nonexistent node `setgid' (perhaps incorrect sectioning?).
    libc.tex:123: Menu reference to nonexistent node `nice' (perhaps incorrect sectioning?).
    libc.tex:122: Menu reference to nonexistent node `mknod' (perhaps incorrect sectioning?).
    libc.tex:121: Menu reference to nonexistent node `mkfifo' (perhaps incorrect sectioning?).
    libc.tex:120: Menu reference to nonexistent node `lchown' (perhaps incorrect sectioning?).
    libc.tex:119: Menu reference to nonexistent node `getpwuid' (perhaps incorrect sectioning?).
    libc.tex:118: Menu reference to nonexistent node `getpwnam' (perhaps incorrect sectioning?).
    libc.tex:117: Menu reference to nonexistent node `getgroups' (perhaps incorrect sectioning?).
    libc.tex:116: Menu reference to nonexistent node `getgrnam' (perhaps incorrect sectioning?).
    libc.tex:115: Menu reference to nonexistent node `getgrgid' (perhaps incorrect sectioning?).
    libc.tex:114: Menu reference to nonexistent node `fork' (perhaps incorrect sectioning?).
    libc.tex:113: Menu reference to nonexistent node `fchown' (perhaps incorrect sectioning?).
    libc.tex:112: Menu reference to nonexistent node `chown' (perhaps incorrect sectioning?).
    libc.tex:111: Menu reference to nonexistent node `cfsetospeed' (perhaps incorrect sectioning?).
    libc.tex:110: Menu reference to nonexistent node `cfsetispeed' (perhaps incorrect sectioning?).
    libc.tex:109: Menu reference to nonexistent node `cfgetospeed' (perhaps incorrect sectioning?).
    libc.tex:108: Menu reference to nonexistent node `cfgetispeed' (perhaps incorrect sectioning?).
    libc.tex:107: Menu reference to nonexistent node `addmntent' (perhaps incorrect sectioning?).
    libc.tex:71: Cross reference to nonexistent node `libm' (perhaps incorrect sectioning?).

    I use makeinfo.exe from txi413br3.zip. What could be the reason?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Tue Feb 22 21:28:46 2022
    Date: Tue, 22 Feb 2022 10:28:29 -0800 (PST)
    From: "Khusraw (mv.ionascu@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>

    When I try to build DJGPP from CVS I get the following errors:

    libc.tex:134: Menu reference to nonexistent node `waitpid' (perhaps incorrect sectioning?).
    libc.tex:133: Menu reference to nonexistent node `wait' (perhaps incorrect sectioning?).
    libc.tex:132: Menu reference to nonexistent node `vfork' (perhaps incorrect sectioning?)
    libc.tex:131: Menu reference to nonexistent node `umask' (perhaps incorrect sectioning?)
    libc.tex:130: Menu reference to nonexistent node `tcsetpgrp' (perhaps incorrect sectioni
    libc.tex:129: Menu reference to nonexistent node `tcsendbreak' (perhaps incorrect sectio
    libc.tex:128: Menu reference to nonexistent node `tcdrain' (perhaps incorrect sectioning
    libc.tex:127: Menu reference to nonexistent node `setuid' (perhaps incorrect sectioning?).
    libc.tex:126: Menu reference to nonexistent node `setsid' (perhaps incorrect sectioning?).
    libc.tex:125: Menu reference to nonexistent node `setpgid' (perhaps incorrect sectioning?).
    libc.tex:124: Menu reference to nonexistent node `setgid' (perhaps incorrect sectioning?).
    libc.tex:123: Menu reference to nonexistent node `nice' (perhaps incorrect sectioning?).
    libc.tex:122: Menu reference to nonexistent node `mknod' (perhaps incorrect sectioning?).
    libc.tex:121: Menu reference to nonexistent node `mkfifo' (perhaps incorrect sectioning?).
    libc.tex:120: Menu reference to nonexistent node `lchown' (perhaps incorrect sectioning?).
    libc.tex:119: Menu reference to nonexistent node `getpwuid' (perhaps incorrect sectioning?).
    libc.tex:118: Menu reference to nonexistent node `getpwnam' (perhaps incorrect sectioning?).
    libc.tex:117: Menu reference to nonexistent node `getgroups' (perhaps incorrect sectioning?).
    libc.tex:116: Menu reference to nonexistent node `getgrnam' (perhaps incorrect sectioning?).
    libc.tex:115: Menu reference to nonexistent node `getgrgid' (perhaps incorrect sectioning?).
    libc.tex:114: Menu reference to nonexistent node `fork' (perhaps incorrect sectioning?).
    libc.tex:113: Menu reference to nonexistent node `fchown' (perhaps incorrect sectioning?).
    libc.tex:112: Menu reference to nonexistent node `chown' (perhaps incorrect sectioning?).
    libc.tex:111: Menu reference to nonexistent node `cfsetospeed' (perhaps incorrect sectioning?).
    libc.tex:110: Menu reference to nonexistent node `cfsetispeed' (perhaps incorrect sectioning?).
    libc.tex:109: Menu reference to nonexistent node `cfgetospeed' (perhaps incorrect sectioning?).
    libc.tex:108: Menu reference to nonexistent node `cfgetispeed' (perhaps incorrect sectioning?).
    libc.tex:107: Menu reference to nonexistent node `addmntent' (perhaps incorrect sectioning?).
    libc.tex:71: Cross reference to nonexistent node `libm' (perhaps incorrect sectioning?).

    I use makeinfo.exe from txi413br3.zip. What could be the reason?

    Did the file libc2.tex get built by the build procedure? Does that
    file have a @node named "waitpid"?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Khusraw@21:1/5 to All on Tue Feb 22 13:38:54 2022
    Yes, it got built, but has no such node, this is its whole content:

    @c -----------------------------------------------------------------------------
    @node Functional Categories, Alphabetical List, Introduction, Top
    @unnumbered Functional Categories

    @menu
    @end menu
    @c -----------------------------------------------------------------------------
    @node Alphabetical List, Unimplemented, Functional Categories, Top
    @unnumbered Alphabetical List

    @menu
    @end menu

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Wed Feb 23 05:29:48 2022
    Date: Tue, 22 Feb 2022 13:38:54 -0800 (PST)
    From: "Khusraw (mv.ionascu@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>

    Yes, it got built, but has no such node, this is its whole content:

    @c -----------------------------------------------------------------------------
    @node Functional Categories, Alphabetical List, Introduction, Top
    @unnumbered Functional Categories

    @menu
    @end menu
    @c -----------------------------------------------------------------------------
    @node Alphabetical List, Unimplemented, Functional Categories, Top @unnumbered Alphabetical List

    @menu
    @end menu

    Then you need to investigate why: this is the problem, AFAIR. This
    file should have the entire contents of the manual, generated from all
    the *.txh files spread all over the source tree.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Khusraw@21:1/5 to All on Wed Feb 23 01:14:01 2022
    Then you need to investigate why: this is the problem, AFAIR. This
    file should have the entire contents of the manual, generated from all
    the *.txh files spread all over the source tree.

    Unfortunately I don't have time for such investigations, I thought that if I have all the
    latest required DJGPP packages installed and run "make" everything is built without
    problems (the error appears in both NTVDM and DOSBox, the only "systems" I have available for building). But I noticed something else, if I run "mkdoc . libc2.tex"
    outside the building process, libc2.tex is correctly generated and the building process
    continues with no more errors.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Khusraw@21:1/5 to All on Wed Feb 23 01:42:05 2022
    I forgot to mention that there was another problem, with gcc failing to
    compile mcount.c due to some warnings being treated as errors, but,
    obviously, I could easily fix this step. My impression is that in fact none
    of those advised has ever tried to build DJGPP from CVS with the
    latest packages and the existing makefiles.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Wed Feb 23 09:00:35 2022
    On 2/23/2022 4:42 AM, Khusraw (mv.ionascu@gmail.com) [via
    djgpp@delorie.com] wrote:
    My impression is that in fact none
    of those advised has ever tried to build DJGPP from CVS with the
    latest packages and the existing makefiles.

    Hi Khusraw,

    Personally, I have not tried to build DJGPP from latest CVS in quite
    some time.  And admittedly, there's only a small handful of people still working on the project.  The heydays of having many eyeballs on DJGPP
    and getting things resolved quickly has since passed.  Is there a
    specific reason you must have DJGPP?  Are you specifically trying to
    target DOS?  If no, then you should be able to use MSYS2/MinGW for your projects.  Also, there is a user who has been building Windows
    cross-compilers for DJGPP for quite some time.  This will build much
    faster (you can actually use -j option in make) and you won't have to
    run it under some form of emulation:
    https://github.com/andrewwutw/build-djgpp

    Frank

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Wed Feb 23 20:41:56 2022
    Am Wed, 23 Feb 2022 01:14:01 -0800 (PST)
    schrieb "Khusraw (mv.ionascu@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>:

    Then you need to investigate why: this is the problem, AFAIR. This
    file should have the entire contents of the manual, generated from
    all the *.txh files spread all over the source tree.

    Unfortunately I don't have time for such investigations, I thought
    that if I have all the latest required DJGPP packages installed and
    run "make" everything is built without problems (the error appears in
    both NTVDM and DOSBox, the only "systems" I have available for
    building). But I noticed something else, if I run "mkdoc . libc2.tex"
    outside the building process, libc2.tex is correctly generated and
    the building process continues with no more errors.

    OFYI, I have build today's cvs repository code of libc without any
    issue with my DJGPP system. It uses bnu2351b, gcc346b, gpp346b,
    mak43b, txi413br3 and all the other stock programs that are required.
    I have not expirienced absolute no issues at all.
    I use VMware and nothing else. I have tested this using Win98se,
    MSDOS-6.22, FreeDOS 1.3 and WinXPSP3. Especially I have never cared
    about any other compiler than gcc346. IMHO, this seems to be an issue
    with your particular installation.

    Regards,
    Juan M. Guerrero

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Khusraw@21:1/5 to All on Thu Feb 24 04:56:10 2022
    OFYI, I have build today's cvs repository code of libc without any
    issue with my DJGPP system. It uses bnu2351b, gcc346b, gpp346b,
    mak43b, txi413br3 and all the other stock programs that are required.
    I have not expirienced absolute no issues at all.
    I use VMware and nothing else. I have tested this using Win98se,
    MSDOS-6.22, FreeDOS 1.3 and WinXPSP3. Especially I have never cared
    about any other compiler than gcc346. IMHO, this seems to be an issue
    with your particular installation.

    Indeed, with gcc346b, gpp346b and mak43b everything is built correctly
    without any modifications, but not with gcc1030b, gpp1030b and mak41br2
    (make 4.3 does not work with gcc 10.3.0, it crashes). Anyway, I renounced
    to gcc 10.3.0 because it is very slow (and I suppose that the previous versions
    from the last years are the same), I will stay with gcc 3.4.6.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Khusraw@21:1/5 to All on Thu Feb 24 10:39:33 2022
    Testing for longer I could note that there are crashes on both my
    available "systems" when I use make 4.3 with gcc 3.4.6 too, though
    not as frequent as with gcc 10.3.0. So I recommend the use of
    make 4.1, I haven't seen yet any crash with it, and I tested it for
    even longer.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Thu Feb 24 21:53:54 2022
    Am Thu, 24 Feb 2022 10:39:33 -0800 (PST)
    schrieb "Khusraw (mv.ionascu@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>:

    Testing for longer I could note that there are crashes on both my
    available "systems" when I use make 4.3 with gcc 3.4.6 too, though
    not as frequent as with gcc 10.3.0. So I recommend the use of
    make 4.1, I haven't seen yet any crash with it, and I tested it for
    even longer.


    I have observed the same. As far as I can tell the issue is related to
    the nmalloc used in djdev205. When I compile ports for DJGPP, I always
    use the current cvs repository code and replace the nmalloc stuff with
    the old malloc stuff. This issue has been brought to my attention in:
    https://www.delorie.com/archives/browse.cgi?p=djgpp/2020/05/01/00:19:09
    and I have tried to debug this for a couple of months but I fear that I
    am to dumb for this task. It seems clear that after certain amount of
    memory consumption due to recursive call of certain functions in the
    make program certain nmalloc tables get corrupted. I have given up to
    trace down this issue long time ago so do not ask me any details. I
    have forgotten about them but if you experience crashes of the make
    program, you can try to trace down it by yourself. The only thing you
    need to do it to compile libc.a with -g -O0 and then compile the make
    program with -g -O0 too.
    The -O0 has absolute no impact on the crash. It will crash anyway
    under the right circumstances. If not you can reproduced the bug as
    described in the thread above.
    Of course, this is not related only to the make program; som other
    programs will exhibit the same memory failure under the right
    circunstances too. I have stoped using nmalloc at all because I do not
    have the time to fix it and I have started to use the old malloc code
    again in all the ports I have uploaded since then. I am not claiming
    that the nmalloc is bad, I am simply telling that there is some subtle
    bug in it that may be triggered under the right conditions.

    Regards,
    Juan M. Guerrero

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Fri Feb 25 08:53:48 2022
    Date: Thu, 24 Feb 2022 21:53:54 +0100
    From: "Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com]" <djgpp@delorie.com>

    Am Thu, 24 Feb 2022 10:39:33 -0800 (PST)
    schrieb "Khusraw (mv.ionascu@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>:

    Testing for longer I could note that there are crashes on both my
    available "systems" when I use make 4.3 with gcc 3.4.6 too, though
    not as frequent as with gcc 10.3.0. So I recommend the use of
    make 4.1, I haven't seen yet any crash with it, and I tested it for
    even longer.

    I have observed the same. As far as I can tell the issue is related to
    the nmalloc used in djdev205. When I compile ports for DJGPP, I always
    use the current cvs repository code and replace the nmalloc stuff with
    the old malloc stuff. This issue has been brought to my attention in:
    https://www.delorie.com/archives/browse.cgi?p=djgpp/2020/05/01/00:19:09
    and I have tried to debug this for a couple of months but I fear that I
    am to dumb for this task. It seems clear that after certain amount of
    memory consumption due to recursive call of certain functions in the
    make program certain nmalloc tables get corrupted. I have given up to
    trace down this issue long time ago so do not ask me any details.

    If nmalloc causes such hard-to-debug problems, I think we should go
    back to the "old" malloc ASAP. It makes no sense to me to produce
    newer ports on such an unstable basis.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)