Messages

1

Virtualization / Re: How to create Virtual Box floppy disk images without any cruft!

« on: August 25, 2024, 02:45:12 am »

You are correct for standard media.  Not entirely unexpectedly, Michal has written a bit about this topic

  http://www.os2museum.com/wp/the-xdf-diskette-format/

  http://www.os2museum.com/wp/floppy-capacity-math/

2

Applications / Re: Cannot create archive

« on: August 25, 2024, 02:26:08 am »

Yes. Thanks for seeing it.

3

Internet / Re: Dooble releases-Qt6

« on: August 24, 2024, 10:14:08 pm »

Qt5WebC.dll is large because it's a test build that includes HLL debug data.  If you lxlite the DLL, the debug data will be removed and you will not get anything resembling a useful exceptq report.  If you are not going to report defects, this will not matter.

4

Virtualization / Re: How to create Virtual Box floppy disk images without any cruft!

« on: August 24, 2024, 09:37:56 pm »

The 2.88MB diskettes should be XDF format.  To read these, you need the XDF filter driver installed.  See:

  https://www.os2world.com/forum/index.php?topic=1902.0

I don't recall if the filter supported write operations.

5

Applications / Re: Cannot create archive

« on: August 24, 2024, 09:10:20 pm »

Good to hear that toggling the enable was sufficient.

FTR, if all else fails, there's \os2\arcinst.exe. This rebuilds the \os2\archives directory tree and is what the installer uses to initialize \os2\archives the first time.

I find it useful to run archinst a couple of time a year to ensure that the Original Archive (i.e. 0) is in sync with the modifications that have been applied to the files named in \os2\archives\*.key.

6

Applications / Re: ANPM database error

« on: August 15, 2024, 10:33:51 pm »

A couple of comments which hopefully will reduce the confusion rather than increase it.

The correct repository URLs can be found at

  https://www.arcanoae.com/wiki/anpm

The link to the Arca Noae mirror of the netlabs-rel repo is

  https://www.2rosenthals.com/rpm.netlabs.org/release/$releasever/$basearch/

which decodes to
   
  https://www.2rosenthals.com/rpm.netlabs.org/release/00/i386/

The repo URLs that contain repos.arcanoae.com only apply to Arca Noae supplied packages.  They cannot be used to install netlabs supplied packages.

The netlabs-rel repo is at

  http://rpm.netlabs.org/release/$releasever/$basearch/
 
which decodes to

   http://rpm.netlabs.org/release/00/i386/

The mirror content is close but not exactly the same as what's at netlabs.  It's supposed to be, but perhaps the netlabs server issues caused the mirror operation to fail in some ways.  This would be a question for Lewis.

Lewis is building the yum metadata locally until netlabs is fully back in service.  This metadata will only include files that the mirror contains.

If someone needs to install a specific package not known to the mirror, you can download the rpm package from the netlabs repo and use anpm or rpm to install it.  For those using the pentium4 platform, the netlabs rpms are at

  http://rpm.netlabs.org/release/00/i386/pentium4/

These do not seem to be affected the netlabs server issues.

7

Programming / Re: GCC - updates

« on: August 06, 2024, 07:13:32 am »

FWIW, running

  gcc -v -Zexe helloworld.c

will give better debugging output for this issue.

Also, it occurs to me that rather than rebuilds gcc, we can experiment with the specs by running

  gcc -specs=my.specs -v -Zexe helloworld.c

where my.specs is the edited output of

  gcc -dumpspecs >my.specs

I'll experiment with this and see what is revealed.

The missing basename implies that for:

gcc\gcc.cc:6168
       if (this_is_output_file || !outbase_length)
         obstack_grow (&obstack, input_basename, basename_length);
       else
         obstack_grow (&obstack, outbase, outbase_length);

neither input_basename or outbase is getting set.  This is unexpected since it appears that in 9.2.0 input_basename was
providing the value for %b.

8

Programming / Re: GCC - updates

« on: August 05, 2024, 10:19:44 am »

The %b substitution is at

gcc\gcc.cc:6161
     case 'b':
       /* Don't use %b in the linker command.  */
#ifndef __OS2__ /* this causes 'internal compiler error: in do_spec_1, at gcc.c:6063' with GCC 11.x - dunno why - FIXME */
       gcc_assert (suffixed_basename_length);
#endif
       if (!this_is_output_file && dumpdir_length)
         obstack_grow (&obstack, dumpdir, dumpdir_length);
       if (this_is_output_file || !outbase_length)
         obstack_grow (&obstack, input_basename, basename_length);
       else
         obstack_grow (&obstack, outbase, outbase_length);

We don't have source debug in this part of the code, but I can see the incorrect insertion into the obstack.  This is probably the dumpdir value.  The specs docs imply that we need a %w to have this_is_output_file set.

I'm thinking that if outbase is set correctly, editing the built-in specs to add a %w before the %b might be the fix.

For 9.2.0, the code is quite different.

gcc\gcc.c:5333
     case 'b':
       if (save_temps_length)
         obstack_grow (&obstack, save_temps_prefix, save_temps_length);
       else
         obstack_grow (&obstack, input_basename, basename_length);
       if (compare_debug < 0)
         obstack_grow (&obstack, ".gk", 3);
       arg_going = 1;
       break;

Hopefully, this will save you some time.

9

Programming / Re: GCC - updates

« on: August 05, 2024, 03:33:15 am »

The reason that gcc with a -o option generates a.exe is because an incorrect value is being passed to the specs processing code for the link options.  To dump a copy of the specs, use

  gcc -dumpspecs >gcc1420.specs

The gory details of spec file syntax is at

  https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html

To see how gcc is processing the specs, use something like

 gcc -v tmp.c

where tmp.c is minimal c program.  I used

  g++ -t -t v xcpt.cpp

because it was handy.  The g++ output includes

COLLECT_GCC_OPTIONS='-pipe' '-v' '-t' '-t' '-mtune=generic' '-march=i686' '-dumpdir' 'a.'
 ld.exe -o a.exe -t -t /@unixroot/usr/lib/crt0.o -LD:/usr2/local1420/bin/../lib/gcc/i686-pc-os2-emx/14 -LD:/usr2/local1420/bin/../lib/gcc -LD:/USR2/LOCAL1420/lib -L. -LD:/usr2/local1420/bin/../lib/gcc/i686-pc-os2-emx/14/../../.. -L/@unixroot/usr/lib E:\TMP/ccc6HJA2.o -lstdc++ -lm -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2

which is consistent with the symptoms.  Note that the COLLECT_GCC_OPTIONS value for 9.2.0 omits the -dumpdir option, but this has no effect on the -o logic.

The -o is generated by the part of the *link: action that reads

 %{!o*:-o %b%{Zdll|shared:.dll}%{!Zdll:%{!shared:%{!Zexe:.exe}}}}

which says if there is no explict -o switch use the value of the %b variable to build the executable name.

What we need to do is track down where %b is set and figure out why it defaults to "a" in 14.2.0.  I suspect a lost patch since gcc on other plaforms is going to default the executable name to a.out.

FWIW, -t -t option sequence in my testcase has no effect here since emxomfld is not used.

10

Applications / Re: Unzip Version 6.0 hangs when booting to a commandline

« on: August 02, 2024, 05:55:37 pm »

Lars,

It appears you are not aware that the sources are available at https://svn.arcanoae.com/prewrite.   See \sys\doc\PREWRITE\prewrite.txt on an ArcaOS install.  Prewrite is effectively part of kLIBC, so this is required.

Are you sure you are running prewrite.dll v0.2.1?  Earlier releases did not check if PM was running.

The calling convention for the hook entry point is whatever kLIBC requires.  It's probably cdecl.  It's been a while since I looked at the sources.

Since you still get a hang if you remove LIBC_HOOK_DLLS from the environment, it would indicate you have two, possibly unrelated, issues.

11

Applications / Re: Unzip Version 6.0 hangs when booting to a commandline

« on: August 02, 2024, 06:51:31 am »

As Alex mentioned, prewrite.dll has replaced klibccfg.dll.  I forget the exact reasons, but one was that defects showed up and the sources had gotten lost.  This happened early 2017.

FWIW, unzip from a command line boot should run normally when prewrite.dll is the hook DLL.  Prewrite checks if pmwp.dll is loaded and exits silently if pmwp.dll is not loaded.  This means that libcn0.dll will use only the built-in mapping rules.

12

Programming / Re: GCC - updates

« on: July 29, 2024, 06:13:38 am »

Hi,

Thanks for the build.  I built an xcpt.exe with 9.2 the other day and it allowed me see how a working version works.  I'll verify that your 12.4.0 version behaves similarly.  I still need to fully understand what populates the seen_objects and unseen_objects list.  These lists never get populated in the failing 13.3.0 build.  So when throw goes looking for the address of the catch code, it can't find it and the assertion fails.

13

Programming / Re: GCC - updates

« on: July 28, 2024, 02:21:52 am »

Hi Paul,

The exceptq report is coming from the failed assert at:

unwind-dw2.c:1335
  code = uw_frame_state_for (context, &fs);
  gcc_assert (code == _URC_NO_REASON);

code is set to _URC_END_OF_STACK (5) because uw_frame_state_for cannot find the address it was
requested to find (in this case 0x139ED)

The failing call path is

  uw_init_context_1 ->
    uw_frame_state_for ->
      _Unwind_Find_FDE

and _Unwind_Find_FDE fails so uw_frame_state_for fails.

Note when debugging with idebug, you need to run idebug -i xcpt.exe.  For some reason, the debugger thinks the failing code
is startup code.  I'm not sure why.  I suspect it's because something is not getting added to either the seen_objects or unseen_objects list.

If this is not enough to fix 13.x, please do a working debug build of xcpt.cpp with gcc 12 so that I can look at what's different about the objects list.

14

Networking / Re: Samba groups are broken

« on: July 26, 2024, 01:09:43 am »

If you want to debug this on your system, here are a couple of ideas in case you have not already tried them.

If you grab a copy of the smbusers sources from

  http://svn.netlabs.org/repos/samba/trunk/guitools/smbusers

you might find it easier to follow the code path

The message

  Samba groups are broken, only 0 instead of 9 groups found

is defined at

  guitools\smbusers\rc\lang\smbusers_en.mkm:129
  SMU0112I: Samba groups are broken, only %1 instead of %2 groups found.

and generated for display at

guitools\smbusers\SMBUSERS.VRX:1278
        Msg.Text = NLVGetMessage(112, gline.0, gname.0)

The 0 in gline.0 is the result of the output of the net rpc command invoked at:

guitools\smbusers\SMBUSERS.VRX:1231
    address cmd samba.!netexe' rpc group -l 'DebugLevel' 'UserCred' 1>'grouplistf' 2>'samba.!error

The code that follows parses the content of the "grouplistf" file and sets gline.0

The grouplistf file name is defined at

guitools\smbusers\SMBUSERS.VRX:1227
    grouplistf = TempDir'netgrouplist.txt'

The content of this file might give you some ideas as to what is not working correctly.  You are either getting no output from the net rpc command or output that the code does not understand.

If the file content is not helpful, mapping

    address cmd samba.!netexe' rpc group -l 'DebugLevel' 'UserCred' 1>'grouplistf' 2>'samba.!error

to something you can run from the command line might give you some useful information.  You can start with

  net rpc group -l

and add options as you go.

The samba.!error file might also contain some useful info.  The file is generated by:

guitools\shared\cltinit.vrs:205
    samba.!error = SysTempFileName(TempDir'smb_err.')

so look for the newest smb_err.* file in your temp directory.

15

Programming / Re: GCC - updates

« on: July 25, 2024, 10:44:55 pm »

If I had to guess, I suspect the changed code is a side effect of the removal of .stabs support.  Without the .stabs entry, there is no obvious way to reference what appears to be a static constructor.

In the 13x, it appears that the static constructor is gone, probably because the code generator has be updated or possibly because the default compiler options have changed.

The exceptq report does not contain sufficient dis-assembly for me to see how the address in EBX is calculated.  Please upload a version of xcpt.exe with debug debug and I'll see if I can figure out where the bad address is coming from.