OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: Paul Smedley on March 16, 2022, 09:57:02 am

Title: GCC - updates
Post by: Paul Smedley on March 16, 2022, 09:57:02 am
Hi  All,

These have all been posted in the FORTRAN thread (https://www.os2world.com/forum/index.php?topic=3017), however people may  not have realised that I've updated GCC recently.

I built:
- GCC 9.4.0 - https://smedley.id.au/tmp/gcc-9.4.0-os2-20220314b.zip
- GCC 10.3.0 - https://smedley.id.au/tmp/gcc-10.3.0-os2-20220314.zip
- GCC 11.2.0 -  https://smedley.id.au/tmp/gcc-11.2.0-os2-20220316.zip

These have  had various degrees of testing, and importantly, Dave has had issues building XUL.DLL from Mozilla with my builds vs the latest BWW builds.

Any and all feedback appreciated :)

Cheers,

Paul
Title: Re: GCC - updates
Post by: Paul Smedley on March 20, 2022, 05:07:26 am
Update for GCC  11.2.0: https://smedley.id.au/tmp/gcc-11.2.0-os2-20220320.zip

Rebuilt with -Os vs -O2  which avoids a compiler SIGSEGV on certain source  files.
Title: Re: GCC - updates
Post by: Paul Smedley on March 26, 2022, 07:21:38 am
More updates:
https://smedley.id.au/tmp/gcc-11.2.0-os2-20220326.zip

With help from Steven, the cause of the SIGSEGV has been found :) This seems pretty solid now!
Title: Re: GCC - updates
Post by: Paul Smedley on April 22, 2022, 01:26:32 am
GCC 11.3.0 -  https://smedley.id.au/tmp/gcc-11.3.0-os2-20220422.zip
Title: Re: GCC - updates
Post by: Paul Smedley on May 07, 2022, 11:36:39 am
[U:\DEV]gcc --version
gcc (GCC) 12.1.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Title: Re: GCC - updates
Post by: Neil Waldhauer on May 07, 2022, 03:11:51 pm
Wasn't 12.1 released yesterday?
Title: Re: GCC - updates
Post by: Paul Smedley on May 07, 2022, 11:47:40 pm
Wasn't 12.1 released yesterday?
I got the announcement email on the evening of May 6th (.au time  zone).

There were only a couple of small patches required, doing more testing now,  I'll post a link later today hopefully.

Interestingly, from the release notes:
Code: [Select]
This release deprecates support for the STABS debugging format and
introduces support for the CTF debugging format [1].
Title: Re: GCC - updates
Post by: Dave Yeo on May 08, 2022, 01:11:31 am
How hard would it be to maintain stabs support in your fork? And whatever happened with aout being depreciated?
Title: Re: GCC - updates
Post by: Paul Smedley on May 08, 2022, 01:38:15 am
Hey Dave,

How hard would it be to maintain stabs support in your fork? And whatever happened with aout being depreciated?

No idea re: stabs support. Of course deprecated doesn't *necessarily* mean immediate removal in the next version. There is a bunch of stuff in Samba that is deprecated - but not yet removed. ie SMB1 support.

aout is simpler - gcc only produced assembly - it's the assembler that takes that assembly and turns it into the right object format. So long as long as we have a working version of gas,  we should be ok.

Link to the 12.1.0 build is https://smedley.id.au/tmp/gcc-12.1.0-os2-20220509.zip

Tested:
- building GCC 12.1.10
- building PHP 8.1.5
- building openssl 1.1.1o
- building apr-1.7.0

All seems fine so far, but YMMV

Cheers,

Paul

PS General reminder that if you want to  support future ports there's a Paypal link at https://os2ports.smedley.id.au or it can also be done via the AN store at https://www.arcanoae.com/shop/os2-ports-paul-smedley/
Title: Re: GCC - updates
Post by: Paul Smedley on May 12, 2022, 11:53:45 am
Not that it  seems there's a great deal  (any?) interest, but I'm getting some SIGSEGV building some code today with GCC 12.1.0, really not sure why yet.  Will investigate as time permits.
Title: Re: GCC - updates
Post by: Dariusz Piatkowski on June 10, 2022, 05:11:56 pm
Paul, everyone...

Not that it  seems there's a great deal  (any?) interest...

This always interests me, however I will honestly say I simply do not know how best to "deploy" the non-RPM versions on my machine, which already has the official "gcc (GCC) 9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)" version installed.

I dread the thought of messing this working install up.

So is there a recommendation/standard way to deploy different GCC versions? Those of you who are doing so, what approach are you taking? I'm talking about not just getting the binaries out there, but are you not building GCC version specific environment setup CMDs?, etc???

I suppose a follow-up to the above really is: to what extent can the on-line multi-version-GCC deployment instructions be readily applied in our OS/2 environment?

Thanks for all the work!
Title: Re: GCC - updates
Post by: Dave Yeo on June 10, 2022, 05:38:26 pm
Hi Dariusz,
What I do is unzip the GCC to @unixroot/usr so using GCC 9.4.0 as an example, I have w:\usr\local940. Then in @unixroot/usr/bin I have the attached gcc940env.cmd and run that in the command window where I want to use the new GCC. Line 74 is where you point to the local940 or whichever GCC,
Code: [Select]
call GCC322plus sPath, 'gcc940', 0, sLinker;Adjust the gcc940 line to whichever GCC you're using, I have multiple gcc*env.cmd files for different GCC versions.
Should really double check that this includes all the C++ stuff, KOMH originally did the cmd file quite a while back.
Title: Re: GCC - updates
Post by: Paul Smedley on August 20, 2022, 01:13:03 am
[U:\DEV\gcc-os2]gcc --version
gcc (GCC) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

binaries soon if there's any interest.
Title: Re: GCC - updates
Post by: Andy Willis on August 20, 2022, 02:39:32 am

I dread the thought of messing this working install up.

So is there a recommendation/standard way to deploy different GCC versions? Those of you who are doing so, what approach are you taking? I'm talking about not just getting the binaries out there, but are you not building GCC version specific environment setup CMDs?, etc???


I have a completely working rpm environment.  I also have many (most) of Paul's builds available.
I have several compilers installed so I have a compilers directory.
Under \compilers I have a gcc3.3.5 under which all the others reside:
03-13-22  18:04         <DIR>        0  bin
03-13-22  18:04         <DIR>        0  binutils
03-13-22  18:08         <DIR>        0  doc
03-13-22  18:05         <DIR>        0  i386-pc-os2-elf
03-13-22  18:06         <DIR>        0  i386-pc-os2-emx
03-13-22  18:06         <DIR>        0  include
08-12-17  23:36         <DIR>      124  info
03-13-22  18:07         <DIR>        0  lib
08-12-18   0:37         <DIR>      124  local510
08-12-18   0:51         <DIR>        0  local550
09-02-18  11:03         <DIR>      124  local620
08-12-18   0:40         <DIR>      124  local630
04-13-18  21:21         <DIR>      124  local710
04-13-18  21:18         <DIR>      124  local720
02-24-18  19:54         <DIR>      124  local730
08-09-18   0:59         <DIR>        0  local810
03-24-19  14:56         <DIR>      150  local820
05-05-19   9:56         <DIR>      150  local830
05-05-19   9:39         <DIR>      150  local910
03-13-22  17:47         <DIR>        0  local940
08-16-22  20:44         <DIR>        0  local1030
08-16-22  20:44         <DIR>        0  local1040
08-16-22  20:45         <DIR>        0  local1120
08-16-22  20:45         <DIR>        0  local1130
08-16-22  20:45         <DIR>        0  local1210
08-12-17  23:37         <DIR>      124  man
09-02-18  11:47         <DIR>        0  older
03-13-22  18:07         <DIR>        0  share
(older has 16 versions of 4.x.x)

I have a cmd script in each to set the environment:
Code: [Select]
SET GCCVER=10.4.0
SET GVER=1040
SET GCCDIR=e:\compilers\gcc440\local%GVER%
SET GCCDIR2=e:/compilers/gcc440/local%GVER%
SET GCCMAIN=e:
set GCCBASE=e:/usr
set USRBASE=e:/usr

SET PATH=%GCCDIR%\bin;%GCCDIR%\libexec\gcc\i386-pc-os2-emx\%GCCVER%;%PATH%
SET BEGINLIBPATH=%GCCDIR%\lib;%BEGINLIBPATH%

SET C_INCLUDE_PATH=%GCCDIR2%/lib/gcc/i386-pc-os2-emx/%GCCVER%/include;%GCCDIR2%/include;%USRBASE%/local/include;%GCCBASE%/include;
SET CPLUS_INCLUDE_PATH=%GCCDIR2%/include/c++/%GCCVER%;%GCCDIR2%/include/c++/%GCCVER%/i386-pc-os2-emx;%GCCDIR2%/lib/gcc/i386-pc-os2-emx/%GCCVER%/include;%USRBASE%/local/include;%GCCBASE%/include;
SET CPLUS_INCLUDE_PATH=%CPLUS_INCLUDE_PATH%;%GCCDIR2%/include;%GCCDIR2%/include/c++/backward;%GCCDIR2%/include/c++/%GCCVER%;%GCCDIR2%/include/c++/%GCCVER%/tr1;%GCCBASE%/include;

SET LIBRARY_PATH=%GCCDIR2%/lib/gcc/i386-pc-os2-emx/%GCCVER%;%GCCDIR2%/lib;%GCCDIR2%/lib/gcc/i386-pc-os2-emx/%GCCVER%;%USRBASE%/local/lib;%GCCBASE%/lib;

SET LIB=%LIBRARY_PATH%

This makes changing the version simple for each drop, right at the top.
It places the particular GCC headers and libraries first, then falls to the local lib and headers and finally to the rpm installed ones.
Title: Re: GCC - updates
Post by: Andy Willis on August 20, 2022, 02:41:25 am
[U:\DEV\gcc-os2]gcc --version
gcc (GCC) 12.2.0
binaries soon if there's any interest.

I'm interested.
Title: Re: GCC - updates
Post by: Paul Smedley on August 20, 2022, 07:09:30 am
[U:\DEV\gcc-os2]gcc --version
gcc (GCC) 12.2.0
binaries soon if there's any interest.

I'm interested.

https://smedley.id.au/tmp/gcc-12.2.0-os2-20220820.zip - source is at https://github.com/psmedley/gcc-os2/tree/gcc-12

Feedback appreciated - seems to work as well as 12.1.0 in the tests I've done so far.
Title: Re: GCC - updates
Post by: TeLLie on August 22, 2022, 11:27:36 am
Hi Paul,

Thankz again for the update, slighty tested it on some programs with cmake, qt5 and make, all where compiling fine.

Where some small programs i tested it with.

Keep up the good work :)
Title: Re: GCC - updates
Post by: Paul Smedley on August 23, 2022, 05:22:58 am
Hi Elbert,

Thankz again for the update, slighty tested it on some programs with cmake, qt5 and make, all where compiling fine.

Where some small programs i tested it with.

Keep up the good work :)

Thanks for testing, and confirming things seem to work.

Cheers,

Paul
Title: Re: GCC - updates
Post by: Paul Smedley on April 04, 2023, 10:12:35 pm
Updated GCC 12.2.0 build, which is compatible with rpm. https://smedley.id.au/tmp/gcc-12.2.0-os2-20230404.zip fixes are mainly to do with adding support for drive letters in cxx11::filesystem to fit some Qt 6.5. issues.
Title: Re: GCC - updates
Post by: Paul Smedley on May 09, 2023, 12:08:49 pm
GCC updated to 12.3.0 - https://smedley.id.au/tmp/gcc-12.3.0-os2-20230513.zip
Title: Re: GCC - updates
Post by: KO Myung-Hun on June 16, 2024, 12:57:47 pm
Hi/2.

I've found a problem of gcc v12.3.0.

If an output name of the executable is not given, gcc generates a.exe. For example,

Code: [Select]
    gcc test.c

This should generates test.exe not a.exe.

Maybe this change is your intention ? Or a regression ?

Thanks for your work!
Title: Re: GCC - updates
Post by: Paul Smedley on June 17, 2024, 09:45:20 am
I'll try investigate....
Title: Re: GCC - updates
Post by: Paul Smedley on June 17, 2024, 10:50:25 am
I'll try investigate....

Per https://gcc.gnu.org/pipermail/gcc/2024-June/244138.html -  GCC 12.4.0 should be available on Thursday. I'll try investigate as part of the update to 12.4.0
Title: Re: GCC - updates
Post by: KO Myung-Hun on June 17, 2024, 01:27:48 pm
I'm looking forward to it!
Title: Re: GCC - updates
Post by: Mentore on June 18, 2024, 08:14:27 am
I'm looking forward to it!

Me too!
As soon as I can get back autotools working I'll definitely try it.
Mentore
Title: Re: GCC - updates
Post by: Paul Smedley on June 21, 2024, 12:35:42 am
Hi/2.

I've found a problem of gcc v12.3.0.

If an output name of the executable is not given, gcc generates a.exe. For example,

Code: [Select]
    gcc test.c

This should generates test.exe not a.exe.

Maybe this change is your intention ? Or a regression ?

Thanks for your work!

So this is interesting -  GCC 9.x worked as you expect, GCC 11 and 12 don't. Interestingly on ubuntu, I get an executable a.out

I'll try investigate,  but compared to getting latest  Samba working, this is  comparatively low  proiority. Expect a lightly tested GCC 12.4.0 soon.
Title: Re: GCC - updates
Post by: Dave Yeo on June 21, 2024, 05:04:10 am
Getting an executable named a.out is/used to be the way it worked. Even GCC 2.81 on OS/2 produced an a.out without -Zomf. I think it still needed emxbind to actually run on OS/2.
Title: Re: GCC - updates
Post by: Paul Smedley on June 21, 2024, 10:07:44 am
gcc 12.4.0 intial release is out.... designed to be installed in %unixroot%\usr\local1240 so should play nicely with rpm... just add %unixroot%\usr\local1240\bin to the front of the path..

https://smedley.id.au/tmp/gcc-12.4.0-os2-20240621.zip

Only tested very lightly (ie to make sure it can build itself)
Title: Re: GCC - updates
Post by: KO Myung-Hun on June 21, 2024, 03:41:09 pm
First of all, thanks a lot!

I've done regression test with my own test suites(https://github.com/komh/gcctest). This release passed all tests but it still generates `a.exe'.

Any plan to fix this problem ?
Title: Re: GCC - updates
Post by: Paul Smedley on June 21, 2024, 11:18:16 pm
First of all, thanks a lot!

I've done regression test with my own test suites(https://github.com/komh/gcctest). This release passed all tests but it still generates `a.exe'.

Any plan to fix this problem ?

Thanks for testing...

See my post above this... "I'll try investigate,  but compared to getting latest  Samba working, this is  comparatively low  proiority. Expect a lightly tested GCC 12.4.0 soon."
Title: Re: GCC - updates
Post by: Paul Smedley on July 08, 2024, 01:19:36 am
VERY early days, but...

Code: [Select]
{0}[u:\t] u:\dev\gcc-os2-13.x\host-i686-pc-os2-emx\gcc\xgcc --version
xgcc.exe (GCC) 13.3.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


{0}[u:\t] u:\dev\gcc-os2-13.x\host-i686-pc-os2-emx\gcc\xgcc -BU:/dev/gcc-os2-13.
x/host-i686-pc-os2-emx/gcc/ -O2 -o helloworld.exe helloworld.c

{0}[u:\t] helloworld.exe
Hello, World!

STABS support has been removed, so building with debug symbols will generate errors.

Building libgcc is a pain as for some reason, I'm getting:
Code: [Select]
../.././libgcc/../gcc/common/config/i386/cpuinfo.h: Assembler messages:
../.././libgcc/../gcc/common/config/i386/cpuinfo.h:1718: Error: unknown pseudo-op: `.text.ctors.65434'

I haven't worked out yet what's causing the ".text.ctors.65434" to be generated. For now, I can manually generate cpuinfo.S and remove the offending line and generate cpuinfo.o and I end up with a seemingly working gcc1.dll

Will have to see how things go with building the rest of the compiler...
Title: Re: GCC - updates
Post by: Martin Iturbide on July 08, 2024, 10:13:11 pm
Hi Paul.

I'm sorry I can not provide much feedback here because of my lack of skills on this area, but I appreciate a lot your efforts in something as important as porting this compiler, and thanks for sharing your progress.

Regards
Title: Re: GCC - updates
Post by: Paul Smedley on July 09, 2024, 01:24:58 am
Looks like the best option is to at least partially revert https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600792.html and re-instate stabs support... More when there's  something to share...

Edit: looking promising....
Title: Re: GCC - updates
Post by: Paul Smedley on July 09, 2024, 12:18:30 pm
VERY lightly tested - but early build of GCC 13.3.0 is at https://smedley.id.au/tmp/gcc-13.3.0-os2-20240709.zip

even lighter tested GCC 14.1.0 at https://smedley.id.au/tmp/gcc-14.1.0-os2-20240709.zip

Debug is still broken, but I think I just fixed it  - rebuilding now to test
Title: Re: GCC - updates
Post by: Paul Smedley on July 10, 2024, 02:02:49 am
More testing to be done, but https://smedley.id.au/tmp/gcc-13.3.0-os2-20240710.zip seems to correctly create debug symbols...

GCC 14.1.0  is giving some errors builing libgcc with debug code:
Code: [Select]
during RTL pass: final
../.././libgcc/libgcc2.c: In function '__muldi3':
../.././libgcc/libgcc2.c:538:1: internal compiler error: in eliminate_regs, at reload1.cc:2938
  538 | }
Title: Re: GCC - updates
Post by: Mentore on July 10, 2024, 08:02:18 am
More testing to be done, but https://smedley.id.au/tmp/gcc-13.3.0-os2-20240710.zip seems to correctly create debug symbols...

GCC 14.1.0  is giving some errors builing libgcc with debug code:
Code: [Select]
during RTL pass: final
../.././libgcc/libgcc2.c: In function '__muldi3':
../.././libgcc/libgcc2.c:538:1: internal compiler error: in eliminate_regs, at reload1.cc:2938
  538 | }

As usual, fantastic job Paul.
May I ask if it is possible to directly substitute this over, say, GCC 9.2.0 from the netlabs YUM/RPM repository?
Mentore (still reinstalling ArcaOS beta to work on the italian NLS)
Title: Re: GCC - updates
Post by: Paul Smedley on July 10, 2024, 10:09:33 am
Hey Mentore,

I've deliberately set this up to easily work *with* rpm gcc 9.2.0.

Unzip it to the root of the same drive you have rpm installed on. To switch to a newer gcc, 'set path=c:\usr\local1330\bin;%path%' (or whatever the path is).  GCC 9.2.0 will still be installed into c:\usr\bin and it's easy to change between them.

Cheers,

Paul.
Title: Re: GCC - updates
Post by: Paul Smedley on July 11, 2024, 02:56:06 am
Working debug with 14.1.0  (with a hack still in place):  https://smedley.id.au/tmp/gcc-14.1.0-os2-20240711.zip
Title: Re: GCC - updates
Post by: KO Myung-Hun on July 11, 2024, 08:34:16 am
Hi/2.

For
Quote
Working debug with 14.1.0  (with a hack still in place):  https://smedley.id.au/tmp/gcc-14.1.0-os2-20240711.zip

404 not found error.

For
Quote
even lighter tested GCC 14.1.0 at https://smedley.id.au/tmp/gcc-14.1.0-os2-20240709.zip

1. 'a.exe' is generated unless -o is given.

2. SIGABRT because of C++ exceptions.
Quote
terminate called after throwing an instance of 'std::out_of_range'
terminate called recursively
Testcases are https://github.com/komh/gcctest/blob/master/xcpt.cpp, https://github.com/komh/gcctest/blob/master/cxx11/exception_ptr.cpp.

For
Quote
VERY lightly tested - but early build of GCC 13.3.0 is at https://smedley.id.au/tmp/gcc-13.3.0-os2-20240709.zip

1. 'a.exe' is generated unless `-o' is given.

2. Some symbols are missing:
Quote
g++  -o ctype.exe ctype.o
../../.././libstdc++-v3/libsupc++/eh_personality.cc:457 (g:/usr/local1330/lib/libstdc++.a()): Undefined symbol __Unwind_GetIPInfo referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:157 (g:/usr/local1330/lib/libstdc++.a(guard.o)): Undefined symbol ___gthread_os2_mutex_lock referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:261 (g:/usr/local1330/lib/libstdc++.a(guard.o)): Undefined symbol ___gthread_os2_cond_wait_recursive referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:169 (g:/usr/local1330/lib/libstdc++.a(guard.o)): Undefined symbol ___gthread_os2_mutex_unlock referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:169 (g:/usr/local1330/lib/libstdc++.a(guard.o)): Undefined symbol ___gthread_os2_mutex_unlock referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:157 (g:/usr/local1330/lib/libstdc++.a(guard.o)): Undefined symbol ___gthread_os2_mutex_lock referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:248 (g:/usr/local1330/lib/libstdc++.a(guard.o)): Undefined symbol ___gthread_os2_cond_broadcast referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:169 (g:/usr/local1330/lib/libstdc++.a(guard.o)): Undefined symbol ___gthread_os2_mutex_unlock referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:157 (g:/usr/local1330/lib/libstdc++.a(guard.o)): Undefined symbol ___gthread_os2_mutex_lock referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:248 (g:/usr/local1330/lib/libstdc++.a(guard.o)): Undefined symbol ___gthread_os2_cond_broadcast referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:169 (g:/usr/local1330/lib/libstdc++.a(guard.o)): Undefined symbol ___gthread_os2_mutex_unlock referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:139 (g:/usr/local1330/lib/libstdc++.a(locale.o)): Undefined symbol ___gthread_os2_mutex_unlock referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:127 (g:/usr/local1330/lib/libstdc++.a(locale.o)): Undefined symbol ___gthread_os2_mutex_lock referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:139 (g:/usr/local1330/lib/libstdc++.a(locale.o)): Undefined symbol ___gthread_os2_mutex_unlock referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:139 (g:/usr/local1330/lib/libstdc++.a(locale_init.o)): Undefined symbol ___gthread_os2_mutex_unlock referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:127 (g:/usr/local1330/lib/libstdc++.a(locale_init.o)): Undefined symbol ___gthread_os2_mutex_lock referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:139 (g:/usr/local1330/lib/libstdc++.a(locale_init.o)): Undefined symbol ___gthread_os2_mutex_unlock referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:127 (g:/usr/local1330/lib/libstdc++.a(locale_init.o)): Undefined symbol ___gthread_os2_mutex_lock referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:139 (g:/usr/local1330/lib/libstdc++.a(locale_init.o)): Undefined symbol ___gthread_os2_mutex_unlock referenced from text segment
U:/dev/gcc-os2-13.x/libstdc++-v3/include/bits/locale_facets_nonio.tcc:601 (g:/usr/local1330/lib/libstdc++.a()): Undefined symbol ___chkstk_ms referenced from text segment
U:/dev/gcc-os2-13.x/libstdc++-v3/include/bits/locale_facets_nonio.tcc:610 (g:/usr/local1330/lib/libstdc++.a()): Undefined symbol ___chkstk_ms referenced from text segment
U:/dev/gcc-os2-13.x/libstdc++-v3/include/bits/locale_facets_nonio.tcc:1095 (g:/usr/local1330/lib/libstdc++.a()): Undefined symbol ___chkstk_ms referenced from text segment
U:/dev/gcc-os2-13.x/libstdc++-v3/include/bits/locale_facets_nonio.tcc:1256 (g:/usr/local1330/lib/libstdc++.a()): Undefined symbol ___chkstk_ms referenced from text segment
U:/dev/gcc-os2-13.x/libstdc++-v3/include/bits/locale_facets_nonio.tcc:1277 (g:/usr/local1330/lib/libstdc++.a()): Undefined symbol ___chkstk_ms referenced from text segment
U:/dev/gcc-os2-13.x/libstdc++-v3/include/bits/locale_facets_nonio.tcc:601 (g:/usr/local1330/lib/libstdc++.a()): Undefined symbol ___chkstk_ms referenced from text segment
U:/dev/gcc-os2-13.x/libstdc++-v3/include/bits/locale_facets_nonio.tcc:610 (g:/usr/local1330/lib/libstdc++.a()): Undefined symbol ___chkstk_ms referenced from text segment
U:/dev/gcc-os2-13.x/libstdc++-v3/include/bits/locale_facets_nonio.tcc:1095 (g:/usr/local1330/lib/libstdc++.a()): Undefined symbol ___chkstk_ms referenced from text segment
U:/dev/gcc-os2-13.x/libstdc++-v3/include/bits/locale_facets_nonio.tcc:1256 (g:/usr/local1330/lib/libstdc++.a()): Undefined symbol ___chkstk_ms referenced from text segment
U:/dev/gcc-os2-13.x/libstdc++-v3/include/bits/locale_facets_nonio.tcc:0 (g:/usr/local1330/lib/libstdc++.a()): More undefined symbol ___chkstk_ms refs follow
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:127 (g:/usr/local1330/lib/libstdc++.a(eh_alloc.o)): Undefined symbol ___gthread_os2_mutex_lock referenced from text segment
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:0 (g:/usr/local1330/lib/libstdc++.a(eh_alloc.o)): More undefined symbol ___gthread_os2_mutex_unlock refs follow
U:/dev/gcc-os2-13.x/i686-pc-os2-emx/libstdc++-v3/include/i686-pc-os2-emx/bits/gthr-default.h:127 (g:/usr/local1330/lib/libstdc++.a(eh_alloc.o)): Undefined symbol ___gthread_os2_mutex_lock referenced from text segment
A testcase is https://github.com/komh/gcctest/blob/master/ctype.cpp. However, this error occurs with any other testcases with g++, too.

Thanks a lot!
Title: Re: GCC - updates
Post by: Paul Smedley on July 11, 2024, 09:04:08 am
oops gcc-14.1.0-os2-20240711.zip is there now

GCC 14.1.0 - please retest with latest  drop

GCC 13.3.0 -  suspect you need to manually add the libs with those symbols - the solution is probably to generate a stdcppxx.dll instead of shipping a static lib...

re: a.exe problem - I think I remember something - need to go investigate... I seem to  remember getting an error from gcc around some failed assertion in LINK_SPEC....
Title: Re: GCC - updates
Post by: Mentore on July 11, 2024, 11:15:03 am
Hey Mentore,

I've deliberately set this up to easily work *with* rpm gcc 9.2.0.

Unzip it to the root of the same drive you have rpm installed on. To switch to a newer gcc, 'set path=c:\usr\local1330\bin;%path%' (or whatever the path is).  GCC 9.2.0 will still be installed into c:\usr\bin and it's easy to change between them.

Cheers,

Paul.

Fantastic job Paul, as usual.
Thanks!

Mentore
Title: Re: GCC - updates
Post by: KO Myung-Hun on July 12, 2024, 08:02:19 am
Quote
oops gcc-14.1.0-os2-20240711.zip is there now

GCC 14.1.0 - please retest with latest  drop

I've downloaded and tested it, but it has no differences.

Quote
GCC 13.3.0 -  suspect you need to manually add the libs with those symbols - the solution is probably to generate a stdcppxx.dll instead of shipping a static lib...

I had tested without `-static-libgcc', and failed due to 'undefined symbols'. However, if it is given, it has the same results as 14.1.0.

I've investigated further more, and found that `gcc1.dll' does not have any export entry. As a resut, `libgcc_so_d.a' has no import entries at all. This was the cause.
Title: Re: GCC - updates
Post by: Paul Smedley on July 12, 2024, 09:40:31 am
I can reproduce issue with xcpt.cpp.

ctype.cpp works for me:
Code: [Select]
{0}[u:\dev\gcc-os2-14.x] g++ ctype.cpp

{0}[u:\dev\gcc-os2-14.x] a
default locale:
  Column
  1,Column
  2,Column
  3
  123,456,789
locale with modified ctype:
  Column 1
  Column 2
  Column 3
  123
  456
  789

'g++ -static-libgcc ctype.cpp'  also works for me (with 14.1.0)

I see the missing symbols errors with 13.3.0 - perhaps I've (accidentally?) fixed something locally in 14.1.0!

Latest 14.1.0 is https://smedley.id.au/tmp/gcc-14.1.0-os2-20240712.zip
Title: Re: GCC - updates
Post by: Paul Smedley on July 12, 2024, 11:31:42 am
OK I found the problem with gcc1.dll. New 13.3.0 build coming once it finishes -  most likely Saturday morning my time....

https://smedley.id.au/tmp/gcc-13.3.0-os2-20240712.zip

xcpt.cpp now gives the same results on both 13.3.0 and 14.1.0,  that is:
Code: [Select]
terminate called after throwing an instance of 'char const*'
terminate called recursively

Killed by SIGABRT
pid=0x63dd ppid=0x0048 tid=0x0001 slot=0x001a pri=0x0200 mc=0x0001 ps=0x0010
U:\DEV\GCC-OS2-13.X\A.EXE
Creating 63DD_01.TRP
Moved 63dd_01.TRP to C:\var\log\app\6691818b-63dd_01-A-exceptq.txt
Title: Re: GCC - updates
Post by: KO Myung-Hun on July 12, 2024, 02:08:23 pm
At the beginning, ctype.cpp had no problems with gcc v14.1.0, but with gcc v13.3.0 only.

For both gcc v14.1.0-20240712 and v13.3.0-20240712

They cause SIGSEGV when executing `exception_ptr.exe'.

Quote
g++ -std=c++11 -c -o cxx11/exception_ptr.o cxx11/exception_ptr.cpp
g++  -o cxx11/exception_ptr.exe cxx11/exception_ptr.o
./cxx11/exception_ptr.exe > /dev/null

Killed by SIGSEGV
pid=0x00e2 ppid=0x00e1 tid=0x0001 slot=0x00ad pri=0x0200 mc=0x0001 ps=0x0010
F:\LANG\WORK\TEST\GCCTEST\CXX11\EXCEPTION_PTR.EXE
cs:eip=0000:00000000      ss:esp=0000:00000000      ebp=d003ffff
 ds=021fff8c      es=0000      fs=0000      gs=0000     efl=00000000
eax=021ff70c ebx=021ff730 ecx=00000053 edx=000a3cb3 edi=021ff6f8 esi=1c029d48

I attach .trp file for this.

And SIGABRT.

Quote
Assertion failed: !"Dead lock" || mutex->recursive || ulCount == 1, file
../.././libgcc/gthr-os2.c, line 93

Killed by SIGABRT
pid=0x00e2 ppid=0x00e1 tid=0x0001 slot=0x00ad pri=0x0200 mc=0x0002 ps=0x0017
F:\LANG\WORK\TEST\GCCTEST\CXX11\EXCEPTION_PTR.EXE
Title: Re: GCC - updates
Post by: Paul Smedley on July 13, 2024, 02:31:59 am
I'll dig into this as time permits... there's not a whole lot  of platform specific stuff in libstd++ but there must be some change that's caused this...
Title: Re: GCC - updates
Post by: Paul Smedley on July 20, 2024, 07:56:21 am
If anyone is feeling brave :)

https://smedley.id.au/tmp/binutils-2.42-os2-20240720.zip

add \binutils\lib to libpath & \binutils\bin to path to test....
Title: Re: GCC - updates
Post by: Paul Smedley on July 21, 2024, 11:21:02 am
OK for the xcpt.cpp testcase,  compiled with 'g++ -Zomf -g -static-libgcc -fexceptions -o xcpt.exe xcpt.cpp' I get:
Killed by SIGSEGV
pid=0x0c88 ppid=0x0049 tid=0x0001 slot=0x0074 pri=0x0200 mc=0x0001 ps=0x0010
U:\DEV\GCC-OS2-13.X\XCPT.EXE
XCPT 1:0002043a
cs:eip=032100ff:000f043a      ss:esp=0000:00000000      ebp=01070053
 ds=0000      es=0000      fs=0000      gs=0000     efl=fa100002
eax=0020f9b8 ebx=1ffc9d7c ecx=0020f9cc edx=0020f9f0 edi=00000000 esi=0020ff8c
Creating 0C88_01.TRP
Moved 0c88_01.TRP to C:\var\log\app\669d57c2-0c88_01-XCPT-exceptq.txt

Looks like an issue in libgcc.... possibly also something that needs to be tweaked in gthr-os2.*

exception_ptr.cpp trap  is VERY similar....
Title: Re: GCC - updates
Post by: KO Myung-Hun on July 21, 2024, 01:38:54 pm
If anyone is feeling brave :)

https://smedley.id.au/tmp/binutils-2.42-os2-20240720.zip

add \binutils\lib to libpath & \binutils\bin to path to test....

I'm trying and have no problems so far.

Thanks!
Title: Re: GCC - updates
Post by: Dave Yeo on July 21, 2024, 10:16:30 pm
If anyone is feeling brave :)

https://smedley.id.au/tmp/binutils-2.42-os2-20240720.zip

add \binutils\lib to libpath & \binutils\bin to path to test....

I built SeaMonkey with this and GCC 9.2.0, built fine, have yet to test.
Title: Re: GCC - updates
Post by: Paul Smedley on July 23, 2024, 12:26:28 am
OK for the xcpt.cpp testcase,  compiled with 'g++ -Zomf -g -static-libgcc -fexceptions -o xcpt.exe xcpt.cpp' I get:
Killed by SIGSEGV
pid=0x0c88 ppid=0x0049 tid=0x0001 slot=0x0074 pri=0x0200 mc=0x0001 ps=0x0010
U:\DEV\GCC-OS2-13.X\XCPT.EXE
XCPT 1:0002043a
cs:eip=032100ff:000f043a      ss:esp=0000:00000000      ebp=01070053
 ds=0000      es=0000      fs=0000      gs=0000     efl=fa100002
eax=0020f9b8 ebx=1ffc9d7c ecx=0020f9cc edx=0020f9f0 edi=00000000 esi=0020ff8c
Creating 0C88_01.TRP
Moved 0c88_01.TRP to C:\var\log\app\669d57c2-0c88_01-XCPT-exceptq.txt

Looks like an issue in libgcc.... possibly also something that needs to be tweaked in gthr-os2.*

exception_ptr.cpp trap  is VERY similar....

FWIW - trap from gcc 13.1.0 is very similar -  still review changes between GCC 12 and 13....
Title: Re: GCC - updates
Post by: Paul Smedley on July 23, 2024, 12:02:50 pm
OK,  I think this is a compiler defect. Refer attached different .S files compiled with GCC 12.4.0 and 13.3.0
Title: Re: GCC - updates
Post by: Steven Levine 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.
Title: Re: GCC - updates
Post by: Paul Smedley on July 26, 2024, 10:30:30 am
Hi Steven, Agree on your root cause - for some reason default_stabs_asm_out_constructor & default_stabs_asm_out_destructor are not being output for cpp code. Give me a day or so to try and work out what's changed before I hassle you with a debug xcpt.exe :)
Title: Re: GCC - updates
Post by: Paul Smedley on July 27, 2024, 08:59:59 am
Attached is a zip of a debug build of xcpt.exe

I'm not (yet) any closer to understanding why c++ executables are missing:
Code: [Select]
.stabs "___CTOR_LIST__",22,0,0,__GLOBAL__sub_I_main
.stabs "___DTOR_LIST__",22,0,0,__GLOBAL__sub_D_main

My current ''hunch' is that the code in https://github.com/psmedley/gcc-os2/blob/13.x/libgcc/config/i386/emx-ctordtor.c isn't being invoked...
Title: Re: GCC - updates
Post by: Paul Smedley on July 28, 2024, 12:20:17 am
OK my hunch was wrong - it's https://github.com/psmedley/gcc-os2/blob/13.x/gcc/dbxout.cc#L3980 that isn't being output.  I did a simple test with GCC 12, where I hacked this line to change the output. Now to work out why default_stabs_asm_out_constructor() and default_stabs_asm_out_destructor aren't being used...
Title: Re: GCC - updates
Post by: Steven Levine 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.
Title: Re: GCC - updates
Post by: Paul Smedley on July 28, 2024, 10:56:14 am
Thanks for this...this doesn't help me (yet).  I still think its likely due to the missing ___CTOR_LIST__ / ___DTOR_LIST__ but for the life of me I can't see what's changed to cause them to be missing.

Attached is a debug xcpt.exe built with 12.4.0
Title: Re: GCC - updates
Post by: Steven Levine 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.
Title: Re: GCC - updates
Post by: Paul Smedley on August 03, 2024, 08:47:15 am
1st drop of GCC 14.2.0 - https://smedley.id.au/tmp/gcc-14.2.0-os2-20240803.zip

c++ exception support is still borked.

Edit: it was an assumption that exception supportis still borked. Seems to be working for me! I'm not sure what I did, or perhaps it's due to a change in 14.2.0!
Title: Re: GCC - updates
Post by: KO Myung-Hun on August 03, 2024, 04:38:39 pm
This has passed my regression test.

Thanks a lot!
Title: Re: GCC - updates
Post by: Paul Smedley on August 04, 2024, 12:38:21 am
Thanks for testing KO! Promise I've get around to figuring out  why 'gcc -Zexe test.c' produces a.exe not test.exe soon. I know this behaviour kinda matches *nix behaviour (where a.out) is produced, but it is a regression from earlier OS/2 ports.
Title: Re: GCC - updates
Post by: Steven Levine 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.
Title: Re: GCC - updates
Post by: Paul Smedley on August 05, 2024, 04:45:13 am
Thanks Steven! I have a set of diffs of bww 9.2.0 vs the original code that I plan to comb through to identify deltas with my code.

Now that exception support is working with 14.2.0 this has made it a bit higher up the list :)
Title: Re: GCC - updates
Post by: Steven Levine 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.

Title: Re: GCC - updates
Post by: Paul Smedley on August 05, 2024, 11:29:17 pm
Thanks Steven..

I updated LINK_SPEC to:
Code: [Select]
#define LINK_SPEC                                                              \
  "%{Zexe} %{Zstack*} %{Zlinker*} %{Zmap*} %{Zsym} %{Zdll} %{shared:-Zdll} %{static:-static} " \
  "%{!o*:-o %w%b%{Zdll|shared:.dll}%{!Zdll:%{!shared:%{!Zexe:.exe}}}} "          \
  "%{static:%{Zcrtdll*:%e-static and -Zcrtdll are incompatible}}"              \
  "%{Zomf:%{Zaout:%e-Zomf and -Zaout are incompatible}}"                       \
  "%{Zdll:%{Zexe:%e-Zdll and -Zexe are incompatible}}"                         \
  "%{shared:%{Zexe:%e-shared and -Zexe are incompatible}}"                     \
  "%{Zsmall-conv:%{Zcrtdll*:%e-Zsmall-conv and -Zcrtdll are incompatible}}"

But now I get
Code: [Select]
{0}[u:\dev\gcc-os2-14.x] gcc -Zexe helloworld.c
ld.exe: No such file or directory for .exe
Assertion failed: crumb->x.used.size <= crate->crumb_size, file ./libc-0.1.12/src/emx/src/lib/malloc/ifree.c, line 65

and sure enough adding -t -t gives:
Code: [Select]
Invoking emxbind: emxbind -bq -o .exe C:\var\temp/ccgEvumKldXXXXXX
ld.exe: No such file or directory for .exe
Title: Re: GCC - updates
Post by: Dave Yeo on August 06, 2024, 12:11:36 am
What about without -Zexe? -Zexe exists only to work around makefiles that don't know about exeext or .exe, so not only foo gets built but also foo.exe. Starting with GCC 2.9.x foo became an executable stub pointing to foo.exe.
Should almost never need it now.
Title: Re: GCC - updates
Post by: Steven Levine 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.
Title: Re: GCC - updates
Post by: Paul Smedley on August 06, 2024, 11:27:23 am
It's interesting - at https://github.com/psmedley/gcc-os2/blob/gcc-14.x/gcc/gcc.cc#L8196 suffixed_basename_length has been set (in the case of helloworld.c to 12)  but by https://github.com/psmedley/gcc-os2/blob/gcc-14.x/gcc/gcc.cc#L6291 it's 0.

Weird.

the positive is that if I set '  suffixed_basename_length = 10;' at L6291 then we do get a valid helloworld.exe....
Title: Re: GCC - updates
Post by: Paul Smedley on August 07, 2024, 11:25:46 am
OK suffixed_basename_length is being reset to 0 here - https://github.com/psmedley/gcc-os2/blob/gcc-14.x/gcc/gcc.cc#L9319

I'm thinking in hindsignt that the comment at https://github.com/psmedley/gcc-os2/blob/gcc-14.x/gcc/gcc.cc#L6289 "Don't use %b in the linker command" is perhaps a sign that for whatever reason,  we should not be using %b in the linker command - which we clearly are at https://github.com/psmedley/gcc-os2/blob/gcc-14.x/gcc/config/i386/emx.h#L447

So... we need to re-think how to get the output file name to match the source file name - or accept that we match the defaults on other OS....
Title: Re: GCC - updates
Post by: KO Myung-Hun on August 07, 2024, 04:27:15 pm
Hi/2.

I've fixed and attached the patch.

This is based on 13.3.0. But I think there will be no problem to apply to 14.2.0 tree.

Thanks!
Title: Re: GCC - updates
Post by: Paul Smedley on August 08, 2024, 10:33:14 am
Thanks - this does work - however I still need the hack at https://github.com/psmedley/gcc-os2/blob/gcc-14.x/gcc/gcc.cc#L6290

Edit: haiku had similar issues with %b in LINK_SPEC  - https://discuss.haiku-os.org/t/my-haiku-arm-uefi-port-progress/10736/116?page=6
Title: Re: GCC - updates
Post by: KO Myung-Hun on August 11, 2024, 01:28:40 pm
I think gcc_assert() is intentional to prohibit to use `%b' and/or `%B' in linker command. The comment is for gcc_assert() line.

In future, it would be better to drop to use `%b' on OS/2, too.

`a.exe' vs `name.exe' is not the show stopper.

Thanks!
Title: Re: GCC - updates
Post by: Paul Smedley on August 19, 2024, 10:06:50 am
binutils 2.43.1 - lightly tested - https://smedley.id.au/tmp/binutils-2.43.1-os2-20240819.zip
Title: Re: GCC - updates
Post by: Paul Smedley on February 05, 2025, 09:03:10 am
binutils 2.44 - lightly tested - https://smedley.id.au/tmp/binutils-2.44-os2-20250205.zip
Title: Re: GCC - updates
Post by: KO Myung-Hun on February 05, 2025, 03:19:11 pm
No problems here, thanks!
Title: Re: GCC - updates
Post by: Paul Smedley on February 17, 2025, 06:20:31 am
GCC 15.10 is expected in the coming months...

gcc.exe (GCC) 15.0.1 20250209 (experimental)
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Title: Re: GCC - updates
Post by: Paul Smedley on February 18, 2025, 12:10:49 am
One interesting nit is that when attempting to build something with cmake/ninja in parallel mode, I get:
Code: [Select]
c++.exe: fatal error: cannot execute 'C:/usr/local1501/bin/../libexec/gcc/i686-pc-os2-emx/15/cc1plus.exe': spawnv: Resource busy
compilation terminated.

'ninja -j 1' seems to work OK.
Title: Re: GCC - updates
Post by: KO Myung-Hun on February 18, 2025, 12:20:54 pm
One interesting nit is that when attempting to build something with cmake/ninja in parallel mode, I get:
Code: [Select]
c++.exe: fatal error: cannot execute 'C:/usr/local1501/bin/../libexec/gcc/i686-pc-os2-emx/15/cc1plus.exe': spawnv: Resource busy
compilation terminated.

'ninja -j 1' seems to work OK.

I've encountered this when building gcc v14.2.0 with 'ld.exe'. In my case, adding '-Zomf' to LDFLAGS when building gcc fixed this problem.
Title: Re: GCC - updates
Post by: Paul Smedley on February 18, 2025, 09:51:17 pm
Thanks, but I checked and -Zomf is definitely being used :(
Title: Re: GCC - updates
Post by: KO Myung-Hun on February 19, 2025, 12:54:33 pm
Thanks, but I checked and -Zomf is definitely being used :(

That's too bad. Then how about trying to build with kLIBC ? This could be a regression of LIBCn.
Title: Re: GCC - updates
Post by: Paul Smedley on February 20, 2025, 08:31:43 am
Just noticed something weird about cc1.exe and cc1plus.exe - they have no EA's listed. The equivalent  executables for GCC 14 (and rpm for that matter) have 124 bytes of EA's

Checking the command lines used to build now...

Edit:
Interesting, when built there are no EA's on GCC 14 or 15 - the install must add them....
Edit2: the EA's aren't the problem...
Edit3: found a misapplied diff in libiberty/argv.c - rebuilding....
Title: Re: GCC - updates
Post by: KO Myung-Hun on February 21, 2025, 09:29:13 am
I've confirmed that there are no differences between kLIBC build and LIBCn build.
Title: Re: GCC - updates
Post by: Paul Smedley on February 21, 2025, 09:47:08 am
I've confirmed that there are no differences between kLIBC build and LIBCn build.
Thanks for trying. I looked at some obvious areas of code and can't see what's changed. Still have a few months before 15.1.0 is released :)
Title: Re: GCC - updates
Post by: Paul Smedley on February 23, 2025, 12:15:24 am
So I installed a logging libc... the failed call from g++ is:
Code: [Select]
0003dcb5 01 03 0001 Mesg 0002 __spawnve (2 ms): Calling DosExecPgm pgm: C:/usr/local1501/libexec/gcc/i686-pc-os2-emx/15/cc1plus.exe args: C:/usr/local1501/bin/../libexec/gcc/i686-pc-os2-emx/15/cc1plus.exe\0kLIBC\0\0
0003dcbf 01 03 0001 Mesg 0002 __spawnve (12 ms): DosExecPgm returned 170
0003dcbf 01 03 0000 Mesg 0010 _sys_set_errno: Set errno 16 for OS/2 error 170

The only reference I can find to DosExecPgm and a return code of 170 is http://svn.netlabs.org/libc/ticket/131

Some clues...
GCC 14 - cc1plus.map - 2.8mb
GCC 15 - cc1plus.map - 19.7mb
Title: Re: GCC - updates
Post by: Steven Levine on February 23, 2025, 03:08:35 am
Interesting.  The error implies that the BSS segment is huge (i.e. bigger than 63MB).  For those that don't know, the BSS segment contains static uninitialized data.  This is a bit of a misnomer since the loader zeros the BSS segment when the application is loaded.

To check this do

  lxlite -c:exemap cc1plus.exe >tmp.exemap

and look at the size of object 2.  This will be the BSS segment unless the linkage changed drastically.

For gcc 14, we get

 ├ ## ─ Base ─── Size ──R─W─E─Res─Dis─Shr─Pre─Inv─Swp─Rsd─Loc─A16─32B─Cnf─IOP─
 │  2 02260000 00517B00 ¹ ¹                                        ¹

or about 5MB.  Well within the limits.  For Knut's (I think) testcase, it's

 ├ ## ─ Base ─── Size ──R─W─E─Res─Dis─Shr─Pre─Inv─Swp─Rsd─Loc─A16─32B─Cnf─IOP─
 │  2 00020000 080001C0 ¹ ¹                                        ¹         

or about 128MB.

I prefer to analyze the binaries, but you can get same info from the map file.  For the testcase, it's

  DGROUP                          0002:00000000        080001c0

I'm wondering if there is an overflow in some static data buffer calculation.


Title: Re: GCC - updates
Post by: Paul Smedley on February 23, 2025, 04:32:32 am
Hey Steven,
I'll get you a debug cc1plus.exe once it's rebuilt.

Code: [Select]
à ## Ä Base ÄÄÄ Size ÄÄRÄWÄEÄResÄDisÄShrÄPreÄInvÄSwpÄRsdÄLocÄA16Ä32BÄCnfÄIOPÄ
³  2 032A0000 00B760A0 û û                                        û         

So 12017824 bytes or 12,017,824 - so shouldn't be an issue?

From the map file
Code: [Select]
DGROUP                          0002:00000000        00b75df0
edit: binaries at https://smedley.id.au/tmp/gcc-15.0.1-os2-20250223.zip
Title: Re: GCC - updates
Post by: Steven Levine on February 23, 2025, 10:00:48 am
My current testing says the problem is with fork's limits rather than your cc1plus.exe build per se.  It's too early to say what can be done about this.

The good news is that

  cc1plus --help

appears to run as expected.  Somewhat unexpectedly

  >cc1plus.exe -c xxx

reported

  cc1plus.exe: warning: command-line option '-c' is valid for Modula-2 but not for  C++
  cc1plus.exe: fatal error: xxx: No such file or directory compilation terminated.

which reminded me that gcc supports more than just C and C++.  It may be your build options are such that the size is totally expected.

Poking about, I found

  https://infinitecoder.github.io/posts/2018-03-29-building-gcc-docker-image/

which discusses using the

  --enable-languages

build option to reduce the size of the gcc binaries.  Have you made use of any of these build options to reduce the size of the gcc executables?

A quick scan of the cc1plus.exe --help output implies that gcc supports at least 14 languages.

Now to fade away for the night...

Title: Re: GCC - updates
Post by: Paul Smedley on February 23, 2025, 10:13:27 am
Thanks Steven. We are currently only configuring c & c++:
Code: [Select]
dash ./configure --disable-bootstrap --enable-languages=c,c++ --build=i686-pc-os2-emx --with-sysroot=/@unixroot --prefix=/@unixroot/usr/local1501 --mandir=/@unixroot/usr/local1501/share/man --infodir=/@unixroot/usr/local1501/share/info --enable-shared --enable-threads --enable-checking=release --disable-multilib --with-system-zlib --with-gcc-major-version-only --without-isl --with-tune=generic --with-arch=i686 --with-gnu-as --disable-libstdcxx-pch
I'm currently building a non-debug build - I doubt it will change anything but who knows :)

When it doesn't help I start looking for other configuration options :)
Title: Re: GCC - updates
Post by: KO Myung-Hun on February 23, 2025, 11:13:05 am
This happens to cc1.exe, too.
Title: Re: GCC - updates
Post by: Steven Levine on February 23, 2025, 09:28:40 pm
I can be so brain-dead.  In hindsight the answer to my question is obviously gcc -v.

IAC, I may have found a way toward a solution.  A bit of poking about indicates that the kernel can return ERROR_BUSY if an allocation request for contiguous linear address space fails.  I guess the logic is that this might be a temporary resource limit.

I need to carve out some quality time with the kernel debugger to fully understand where the ERROR_BUSY is coming from.

This convinced me to try highmem -d on a corrected version of Knut's testcase.  Unfortunately highmem marks both the data and stack objects to load high which causes the testcase to trap.  Oops.  exehdr supports marking specific objects, but so far, it's trapping when asked to mark the testcase.

More later...

Exehdr was trapping because it cannot handle long names.  After renaming the testcase to 8.3 format, exehdr marked object 2 to load high.  Unfortunately, this did not avoid the fork failure.
Title: Re: GCC - updates
Post by: Paul Smedley on April 26, 2025, 03:09:31 am
Building the release version of GCC 15.1.0 now - I expect the forking will still be a problem...
Title: Re: GCC - updates
Post by: Paul Smedley on April 26, 2025, 10:10:28 am
Building the release version of GCC 15.1.0 now - I expect the forking will still be a problem...

Code: [Select]
gcc.exe (GCC) 15.1.0
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Title: Re: GCC - updates
Post by: Paul Smedley on April 27, 2025, 02:39:50 am
https://smedley.id.au/tmp/gcc-15.1.0-os2-20250427.zip
Title: Re: GCC - updates
Post by: Dave Yeo on April 27, 2025, 05:12:51 am
404
Title: Re: GCC - updates
Post by: Paul Smedley on April 27, 2025, 05:40:17 am
Sorry, try again...
Title: Re: GCC - updates
Post by: Dave Yeo on April 27, 2025, 05:51:33 am
Thanks, working
Title: Re: GCC - updates
Post by: Paul Smedley on April 27, 2025, 10:10:12 am
I've now built GCC 15.1.0, apache2 and php 8.1 with gcc15.1.0.

I haven't (yet) tried to build with multiple jobs - I suspect this will fail like 15.0.1 did... (ie due to apparent fork()n bugs/limitiations in libc)

Edit: interestingly, qt6-base-os2 appears to be building fine with GCC 15.1.0 - so appears the problems with fork were due to something that was only in the GCC beta code <shrug>
Title: Re: GCC - updates
Post by: Paul Smedley on April 27, 2025, 11:13:39 am
Hey Steven,
I'll get you a debug cc1plus.exe once it's rebuilt.

Code: [Select]
à ## Ä Base ÄÄÄ Size ÄÄRÄWÄEÄResÄDisÄShrÄPreÄInvÄSwpÄRsdÄLocÄA16Ä32BÄCnfÄIOPÄ
³  2 032A0000 00B760A0 û û                                        û         

So 12017824 bytes or 12,017,824 - so shouldn't be an issue?

For cc1plus from 15.1.0:
Code: [Select]
à ## Ä Base ÄÄÄ Size ÄÄRÄWÄEÄResÄDisÄShrÄPreÄInvÄSwpÄRsdÄLocÄA16Ä32BÄCnfÄIOPÄ
³  2 02690000 005B97F0 û û                                        û         

005B97F0 = 6,002,672 - so half the size of 15.0.1

GCC 14.3.0- cc1plus.map - 2.8mb
GCC 15.0.1 - cc1plus.map - 19.7mb
GCC 15.1.0 - cc1plus.map - 3.5mb
Title: Re: GCC - updates
Post by: KO Myung-Hun on April 28, 2025, 11:35:03 am
This has no problems at all with my regression tests, and works fine with 'make -jx'.

Thanks!
Title: Re: GCC - updates
Post by: TeLLie on April 28, 2025, 12:36:18 pm
Hi Paul,

This versions works very well.
Also the -jx  works ok

Greetz Tellie
Title: Re: GCC - updates
Post by: Jochen Schäfer on April 28, 2025, 02:44:56 pm
Just a question: What are we doing to produce OS/2 binaries?
Do we call emxomf, wlink etc. to convert the binaries?
Title: Re: GCC - updates
Post by: Dave Yeo on April 28, 2025, 11:28:59 pm
Just a question: What are we doing to produce OS/2 binaries?
Do we call emxomf, wlink etc. to convert the binaries?

Set up your environment and then the usual gcc flags work.
My gcc1510env.cmd is attached, adjust if needed. Put it on your PATH, execute in a cmd session, check by running gcc-v, then use as older GCC's
Title: Re: GCC - updates
Post by: Paul Smedley on April 29, 2025, 07:26:06 am
Expanding on Dave's comments, I tend to compile in a.out (the default) but then link with -Zomf which makes the compiler invoke emxomfld which uses emxomf and wlink to make the executables or DLLs.

This code is all basically evolved from the earlier gcc 3.x builds.
Title: Re: GCC - updates
Post by: Jochen Schäfer on April 29, 2025, 09:12:20 am
Hi Paul.

Thanks for the answer. So for a cross compiler setup, we would need a port of these emx tools. The OpenWatcom stuff is already there.
Am I correct? (I know, it's certainly not that easy to do)
Title: Re: GCC - updates
Post by: Paul Smedley on April 29, 2025, 10:15:46 am
Hi Jochen,
Thanks for the answer. So for a cross compiler setup, we would need a port of these emx tools. The OpenWatcom stuff is already there.
Am I correct? (I know, it's certainly not that easy to do)
For a cross compiler, we'd also need binutils compiled on the host platform with the changes for os2 a.out. We'd probably also need a port of ld.exe that supports EMX a.out for configure tests.

I've thought about a cross compiler a couple of times and it's made my head hurt.

I'd rather spend energy trying to get wlink to work with coff or gas object files - and trying to update the toolchain to support those.
Title: Re: GCC - updates
Post by: Jochen Schäfer on April 29, 2025, 10:22:30 am
Hi Paul.

Fair enough. I'm just interested, what it would take to have a cross compiler.
Title: Re: GCC - updates
Post by: Paul Smedley on April 29, 2025, 10:25:51 am
Fair enough. I'm just interested, what it would take to have a cross compiler.

Don't get me wrong, there could be definite benefits - for example - building qtwebengine on OS/2 is a PITA due to g++ processes consuming ~2gb of RAM on large compilations, so having to limit the number of ninja processes - building on a modern linux system could allow multiple processes to run without memory exhaustion.
Title: Re: GCC - updates
Post by: Jochen Schäfer on April 29, 2025, 10:53:10 am
Fair enough. I'm just interested, what it would take to have a cross compiler.

Don't get me wrong, there could be definite benefits - for example - building qtwebengine on OS/2 is a PITA due to g++ processes consuming ~2gb of RAM on large compilations, so having to limit the number of ninja processes - building on a modern linux system could allow multiple processes to run without memory exhaustion.
I'm doing the same for the DOSBOX-X cpu core files.
Another benefit would to have Github actions automatically build the code, so we would have some sort of integration test.
Title: Re: GCC - updates
Post by: Dave Yeo on April 29, 2025, 05:15:10 pm
I tried building Qt6 on Linux, it was scarily fast. This I5 went into turbo mode, 3.6 GHz, OS/2 doesn't seem to enable the turbo and stays at 3.2 GHz, and temperatures shot up in this little computer, CPU at close to 90C (60C is about the highest it gets on OS/2) and worse, the NVMe at its max of 85C. Build failed in the webengine and I didn't want to do it again without more cooling.
As for cross-compiling, not only GCC and friends, the EMX toolchain need porting, a lot of other tools have OS/2 specific code. Think of the autotools. Plus there are test programs and such built during a complex build. Some use Rexx too. Possible but a bigger job then likely expected.
Title: Re: GCC - updates
Post by: Pete on April 29, 2025, 10:33:45 pm
Hi Dave

Maybe you want to check out water cooling as it seems to work cooler/quieter than cpu fan type coolers.


Regards

Pete
Title: Re: GCC - updates
Post by: Dave Yeo on April 30, 2025, 01:35:50 am
It's a fairly small computer, https://www.os2world.com/wiki/index.php?title=Lenovo_ThinkCentre_M910s_-_10ML (https://www.os2world.com/wiki/index.php?title=Lenovo_ThinkCentre_M910s_-_10ML) and likely no room in it for a water cooler. I have picked up a small (40mm?) fan to stick in the front, have to figure out the wiring as the fan has 3 wires and the header has 4 wires, also picked up a heat sink for the NVMe. Have to take it apart and add the components and clean it again. I use wood heat and the house is dusty:)
I also see that actually the CPU was faster then I mentioned, 3.4/3.8GHz.
It's a nice little computer, was C$80 used with no storage. Going to a lot of similar on the market as it is just a hair too old to run Win 11 being released in 2019.
Title: Re: GCC - updates
Post by: Remy on April 30, 2025, 01:01:30 pm
It's a fairly small computer, https://www.os2world.com/wiki/index.php?title=Lenovo_ThinkCentre_M910s_-_10ML (https://www.os2world.com/wiki/index.php?title=Lenovo_ThinkCentre_M910s_-_10ML) and likely no room in it for a water cooler. I have picked up a small (40mm?) fan to stick in the front, have to figure out the wiring as the fan has 3 wires and the header has 4 wires, also picked up a heat sink for the NVMe. Have to take it apart and add the components and clean it again. I use wood heat and the house is dusty:)
I also see that actually the CPU was faster then I mentioned, 3.4/3.8GHz.
It's a nice little computer, was C$80 used with no storage. Going to a lot of similar on the market as it is just a hair too old to run Win 11 being released in 2019.

May be you can change the ventirad (heat sink)
e.g. be quiet! Pure Rock LP   (very low profile but a high tdp value (100w) - your cpu is 65w  (this should reduce a lot max temperature)
The high should be good, you may check if the scare width of 92mm is okk too and that it didn't touch ram slots.

https://www.bequiet.com/fr/cpucooler/3992
Title: Re: GCC - updates
Post by: Pete on April 30, 2025, 03:40:10 pm
Hi Dave

I see what you mean.
Looks like a slim case and probably not quite enough room to fit a water radiator to the case rear fan mounting.
Probably have problems with some of the taller air coolers as well.


Regards

Pete
 



Title: Re: GCC - updates
Post by: Paul Smedley on May 03, 2025, 10:52:17 am
just a FYI - gcc 15.1.10 has some issues with libstdc++ filesystem support which prevent syncqt.exe from Qt working, so I can're rebuilt Qt 6.8 with it (older versions don't use a compiled syncqt.exe are are OK).

Couple of different (but maybe related) errors:
Code: [Select]
  what():  filesystem error: cannot get file size: Operation not supported on socket [U:/dev/qt6-base-os2-6.8.x/build-gcc15/include/QtExampleIcons/qtexampleiconsversion.h]
Not a directory(20):filesystem error: cannot create directories: Not a directory [U:/dev/qt6-base-os2-6.8.x/build-gcc15/include/QtCore/6.8.3/QtCore/private]
The fix isn't obvious (yet)
Title: Re: GCC - updates
Post by: Paul Smedley on May 04, 2025, 02:11:17 am
OK I think I've found the root cause of this...
Title: Re: GCC - updates
Post by: Dave Yeo on May 04, 2025, 03:28:58 am
Are you also updating Qt for C++20?
Code: [Select]
:/work/dooble-dry/Source/dooble.cc
In file included from L:/QT6-6.2.X/include/QtCore/qfuture.h:45,
                 from L:/QT6-6.2.X/include/QtCore/QtCore:92,
                 from L:/QT6-6.2.X/include/QtConcurrent/QtConcurrentDepends:3,
                 from L:/QT6-6.2.X/include/QtConcurrent/QtConcurrent:3,
                 from K:/work/dooble-dry/Source/dooble.cc:41:
L:/QT6-6.2.X/include/QtCore/qfutureinterface.h:451:37: error: template-id not al
lowed for constructor in C++20 [-Werror=template-id-cdtor]
  451 |     explicit QFutureInterface<void>(State initialState = NoState)
      |                                     ^~~~~
L:/QT6-6.2.X/include/QtCore/qfutureinterface.h:451:37: note: remove the '< >'
cc1plus.exe: all warnings being treated as errors
make: *** [Makefile:12688: temp/obj/dooble.obj] Error 1
Title: Re: GCC - updates
Post by: Paul Smedley on May 04, 2025, 07:37:16 am
OK I think I've found the root cause of this...

OK https://smedley.id.au/tmp/gcc-15.1.0-os2-20250504.zip should fix the problems with filesystem support in libstdc++

The fix turned out to be pretty simple. I had recently set GCCOPT to -static-libgcc to avoid a dependency on gcc1.dll. However - libstdc++ is built with -shared-libgcc - and the flags conflict - so a bunch of configure tests were failing - which resulted in some broken functionality.
Title: Re: GCC - updates
Post by: Paul Smedley on May 04, 2025, 07:38:00 am
Are you also updating Qt for C++20?
Code: [Select]
:/work/dooble-dry/Source/dooble.cc
In file included from L:/QT6-6.2.X/include/QtCore/qfuture.h:45,
                 from L:/QT6-6.2.X/include/QtCore/QtCore:92,
                 from L:/QT6-6.2.X/include/QtConcurrent/QtConcurrentDepends:3,
                 from L:/QT6-6.2.X/include/QtConcurrent/QtConcurrent:3,
                 from K:/work/dooble-dry/Source/dooble.cc:41:
L:/QT6-6.2.X/include/QtCore/qfutureinterface.h:451:37: error: template-id not al
lowed for constructor in C++20 [-Werror=template-id-cdtor]
  451 |     explicit QFutureInterface<void>(State initialState = NoState)
      |                                     ^~~~~
L:/QT6-6.2.X/include/QtCore/qfutureinterface.h:451:37: note: remove the '< >'
cc1plus.exe: all warnings being treated as errors
make: *** [Makefile:12688: temp/obj/dooble.obj] Error 1
I wsan't planning on it - just remove -Werror from the makefiles..
Title: Re: GCC - updates
Post by: Dave Yeo on May 04, 2025, 07:44:53 am
Are you also updating Qt for C++20?
Code: [Select]
:/work/dooble-dry/Source/dooble.cc
In file included from L:/QT6-6.2.X/include/QtCore/qfuture.h:45,
                 from L:/QT6-6.2.X/include/QtCore/QtCore:92,
                 from L:/QT6-6.2.X/include/QtConcurrent/QtConcurrentDepends:3,
                 from L:/QT6-6.2.X/include/QtConcurrent/QtConcurrent:3,
                 from K:/work/dooble-dry/Source/dooble.cc:41:
L:/QT6-6.2.X/include/QtCore/qfutureinterface.h:451:37: error: template-id not al
lowed for constructor in C++20 [-Werror=template-id-cdtor]
  451 |     explicit QFutureInterface<void>(State initialState = NoState)
      |                                     ^~~~~
L:/QT6-6.2.X/include/QtCore/qfutureinterface.h:451:37: note: remove the '< >'
cc1plus.exe: all warnings being treated as errors
make: *** [Makefile:12688: temp/obj/dooble.obj] Error 1
I wsan't planning on it - just remove -Werror from the makefiles..

A simple good idea. Even better, any idea where the -Werror comes from?
Title: Re: GCC - updates
Post by: Dave Yeo on May 04, 2025, 07:46:43 am
[Even better, any idea where the -Werror comes from?

Of course. dooble.pro
Title: Re: GCC - updates
Post by: Paul Smedley on May 04, 2025, 07:48:47 am
even better - then you do'nt have to keep removing it :)
Title: Re: GCC - updates
Post by: Dave Yeo on May 04, 2025, 08:02:18 am
Unluckily, another problem which I have a vague feeling you figured out before. Using
Code: [Select]
L:\qt6-6.2.x\bin>bldlevel qmake.exe
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#cmake build system:0.0#@##1## 18 Jan 2025 18:18:51     ARCAOS-803C4C0::::0::@@qmake
Vendor:          cmake build system
Revision:        0.00
Date/Time:       18 Jan 2025 18:18:51
Build Machine:   ARCAOS-803C4C0
ASD Feature ID:  4C0
File Version:    0.0
Description:     qmake

I get,
Code: [Select]
[K:\work\dooble-dry\build]make
L:/QT6-6.2.X/bin/qmake.exe -o Makefile K:/work/dooble-dry/dooble.pro
Assertion failed: _UM_LUMP_STATUS (olump) == _UMS_FREE, file U:/DEV/libc-git/src
/emx/src/lib/malloc/ialloc.c, line 116

Killed by SIGABRT
pid=0x0911 ppid=0x0910 tid=0x0001 slot=0x00c3 pri=0x0200 mc=0x0001 ps=0x0010
L:\QT6-6.2.X\BIN\QMAKE.EXE
Creating 0911_01.TRP
Moved 0911_01.TRP to W:\var\log\app\68169e12-0911_01-QMAKE-exceptq.txt
make: *** [Makefile:515: Makefile] Abort trap

Trp attached.
Also want to test changing -O3 to -O2. Over optimization really made Mozilla unstable.
Title: Re: GCC - updates
Post by: Paul Smedley on May 04, 2025, 08:06:43 am
I fixed a similar TRP in qmake for Qt 6.8 - never seen it before in 6.2.x... Interestingly, the TRP looks similar to the one in Qt 6.8.x - perhaps its some kind of compiler optimisation issue?

Edit: I think https://github.com/psmedley/qt6-base-os2/commit/528a156563fee77b310f8bd120c7a7f9178fb802 might be the fix for this. I don't think this fix has made it into a public build. Perhaps rebuild qt6core.dll if you can locally and see if it helps.
Title: Re: GCC - updates
Post by: Dave Yeo on May 04, 2025, 08:18:10 am
It did work here, though the trp seems familiar.
I'll reinstall Qt6 tomorrow and see if that helps.
Title: Re: GCC - updates
Post by: Paul Smedley on May 04, 2025, 08:43:01 am
Turns out I had an updated qt6core.dll built, I just guess I didn't package it up. https://smedley.id.au/tmp/qt6-6.2.x-qt6core-20250204.zip
Title: Re: GCC - updates
Post by: Dave Yeo on May 04, 2025, 08:48:35 am
Turns out I had an updated qt6core.dll built, I just guess I didn't package it up. https://smedley.id.au/tmp/qt6-6.2.x-qt6core-20250204.zip

Thanks, that fixed it
Code: [Select]
[K:\work\dooble-dry\build]make
L:/QT6-6.2.X/bin/qmake.exe -o Makefile K:/work/dooble-dry/dooble.pro
Project MESSAGE: The QtCharts module has been discovered.
make: Nothing to be done for 'first'.

need a make clean or such
Title: Re: GCC - updates
Post by: Paul Smedley on May 25, 2025, 11:52:36 am
GCC 14.3.0 was released a few days ago - OS/2 binaries at https://smedley.id.au/tmp/gcc-14.3.0-os2-20250525.zip
Title: Re: GCC - updates
Post by: Martin Iturbide on May 25, 2025, 06:13:55 pm
Thanks Paul. I also posted it on the OS2World news to see if we get more feedback.

Regards
Title: Re: GCC - updates
Post by: Paul Smedley on August 09, 2025, 11:41:04 am
binaries to follow:
Code: [Select]
gcc.exe (GCC) 15.2.0
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Title: Re: GCC - updates
Post by: Paul Smedley on August 10, 2025, 11:22:42 am
Only tested to confirm it can build itself.... https://smedley.id.au/tmp/gcc-15.2.0-os2-20250810.zip
Title: Re: GCC - updates
Post by: Martin Iturbide on August 10, 2025, 06:37:16 pm
Thank you very much Paul. I can not provide feedback on this, but I appreciate it since gcc is very important to us, to port things from the Linux world.

Regards
Title: Re: GCC - updates
Post by: KO Myung-Hun on August 11, 2025, 06:10:23 am
Hi/2.

Only tested to confirm it can build itself.... https://smedley.id.au/tmp/gcc-15.2.0-os2-20250810.zip

This passed my regression test set. Thanks!
Title: Re: GCC - updates
Post by: Paul Smedley on August 11, 2025, 11:19:40 am
Thanks for testing KO!
Title: Re: GCC - updates
Post by: TeLLie on August 11, 2025, 12:04:02 pm
Hi Paul,

Did test on some small progs, so far so good :)

Greetz Tellie
Title: Re: GCC - updates
Post by: Mentore on August 13, 2025, 09:24:15 am
Only tested to confirm it can build itself.... https://smedley.id.au/tmp/gcc-15.2.0-os2-20250810.zip

Hi Paul, smedley.id.au is not responding right now. Problems?

Mentore
Title: Re: GCC - updates
Post by: Paul Smedley on August 13, 2025, 10:37:47 am
Only tested to confirm it can build itself.... https://smedley.id.au/tmp/gcc-15.2.0-os2-20250810.zip

Hi Paul, smedley.id.au is not responding right now. Problems?

Mentore

Nothing I'm aware of, and website loads for me from a 4G connection....