1
Programming / Re: Qt6 Application Testing
« on: September 24, 2024, 08:00:40 pm »
This one looks familiar. Didn't you already patch blink::ParkableImageManager::Instance() to do proper SSE alignment?
OS2 World Community Forum
OS/2, ArcaOS and eComStation - Warp Community
News:
OS2World.com Forum is back !!!
Remember to visit OS2World at:
http://www.os2world.com
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
Programming / Re: Qt6 Application Testing
« on: September 21, 2024, 12:00:17 am »
Remy,
Are you sure that you did not get corresponding exceptq reports written to %LOGFILES%\app? Normally, the silent exit code will generate an exceptq report with the description
Exception 71785158 - Exceptq Debug Request
The file name will be similar to
4294967295-001e_14-dooble-exceptq.txt
Are you sure that you did not get corresponding exceptq reports written to %LOGFILES%\app? Normally, the silent exit code will generate an exceptq report with the description
Exception 71785158 - Exceptq Debug Request
The file name will be similar to
4294967295-001e_14-dooble-exceptq.txt
3
Programming / Re: Qt6 Application Testing
« on: September 20, 2024, 05:39:38 pm »
Remy,
Are you using Paul's libcn0 build with the silent exit patch? The trap appears to be in the code that implements the exceptq interface.
Are you using Paul's libcn0 build with the silent exit patch? The trap appears to be in the code that implements the exceptq interface.
4
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/
http://www.os2museum.com/wp/the-xdf-diskette-format/
http://www.os2museum.com/wp/floppy-capacity-math/
5
Applications / Re: Cannot create archive
« on: August 25, 2024, 02:26:08 am »
Yes. Thanks for seeing it.
6
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.
7
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.
8
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.
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.
9
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.
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.
10
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.
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.
11
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.
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.
12
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.
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.
13
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.
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.
14
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.
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.
15
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.
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.