OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Programming => Topic started 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
-
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.
-
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!
-
GCC 11.3.0 - https://smedley.id.au/tmp/gcc-11.3.0-os2-20220422.zip
-
[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.
-
Wasn't 12.1 released yesterday?
-
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:
This release deprecates support for the STABS debugging format and
introduces support for the CTF debugging format [1].
-
How hard would it be to maintain stabs support in your fork? And whatever happened with aout being depreciated?
-
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/
-
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.
-
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!
-
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,
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.
-
[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.
-
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:
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.
-
[U:\DEV\gcc-os2]gcc --version
gcc (GCC) 12.2.0
binaries soon if there's any interest.
I'm interested.
-
[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.
-
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 :)
-
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
-
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.
-
GCC updated to 12.3.0 - https://smedley.id.au/tmp/gcc-12.3.0-os2-20230513.zip
-
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,
gcc test.c
This should generates test.exe not a.exe.
Maybe this change is your intention ? Or a regression ?
Thanks for your work!
-
I'll try investigate....
-
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
-
I'm looking forward to it!
-
I'm looking forward to it!
Me too!
As soon as I can get back autotools working I'll definitely try it.
Mentore
-
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,
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.
-
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.
-
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)
-
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 ?
-
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."
-
VERY early days, but...
{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:
../.././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...
-
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
-
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....
-
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
-
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:
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 | }
-
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:
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)
-
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.
-
Working debug with 14.1.0 (with a hack still in place): https://smedley.id.au/tmp/gcc-14.1.0-os2-20240711.zip
-
Hi/2.
For
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
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.
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
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:
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!
-
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....
-
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
-
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.
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.
-
I can reproduce issue with xcpt.cpp.
ctype.cpp works for me:
{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
-
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:
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
-
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'.
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.
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
-
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...
-
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....
-
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....
-
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!
-
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.
-
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....
-
OK, I think this is a compiler defect. Refer attached different .S files compiled with GCC 12.4.0 and 13.3.0
-
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.
-
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 :)
-
Attached is a zip of a debug build of xcpt.exe
I'm not (yet) any closer to understanding why c++ executables are missing:
.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...
-
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...
-
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.
-
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
-
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.
-
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!
-
This has passed my regression test.
Thanks a lot!
-
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.
-
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.
-
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 :)
-
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.
-
Thanks Steven..
I updated LINK_SPEC to:
#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
{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:
Invoking emxbind: emxbind -bq -o .exe C:\var\temp/ccgEvumKldXXXXXX
ld.exe: No such file or directory for .exe
-
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.
-
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.
-
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....
-
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....
-
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!
-
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
-
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!
-
binutils 2.43.1 - lightly tested - https://smedley.id.au/tmp/binutils-2.43.1-os2-20240819.zip
-
binutils 2.44 - lightly tested - https://smedley.id.au/tmp/binutils-2.44-os2-20250205.zip
-
No problems here, thanks!
-
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.
-
One interesting nit is that when attempting to build something with cmake/ninja in parallel mode, I get:
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.
-
One interesting nit is that when attempting to build something with cmake/ninja in parallel mode, I get:
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.
-
Thanks, but I checked and -Zomf is definitely being used :(
-
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.
-
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....
-
I've confirmed that there are no differences between kLIBC build and LIBCn build.
-
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 :)
-
So I installed a logging libc... the failed call from g++ is:
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
-
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.
-
Hey Steven,
I'll get you a debug cc1plus.exe once it's rebuilt.
à ## Ä 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
DGROUP 0002:00000000 00b75df0
edit: binaries at https://smedley.id.au/tmp/gcc-15.0.1-os2-20250223.zip
-
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...
-
Thanks Steven. We are currently only configuring c & c++:
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 :)
-
This happens to cc1.exe, too.
-
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.
-
Building the release version of GCC 15.1.0 now - I expect the forking will still be a problem...
-
Building the release version of GCC 15.1.0 now - I expect the forking will still be a problem...
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.
-
https://smedley.id.au/tmp/gcc-15.1.0-os2-20250427.zip
-
404
-
Sorry, try again...
-
Thanks, working
-
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>
-
Hey Steven,
I'll get you a debug cc1plus.exe once it's rebuilt.
à ## Ä 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:
à ## Ä 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
-
This has no problems at all with my regression tests, and works fine with 'make -jx'.
Thanks!
-
Hi Paul,
This versions works very well.
Also the -jx works ok
Greetz Tellie
-
Just a question: What are we doing to produce OS/2 binaries?
Do we call emxomf, wlink etc. to convert the binaries?
-
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
-
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.
-
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)
-
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.
-
Hi Paul.
Fair enough. I'm just interested, what it would take to have a cross compiler.
-
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.
-
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.
-
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.
-
Hi Dave
Maybe you want to check out water cooling as it seems to work cooler/quieter than cpu fan type coolers.
Regards
Pete
-
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.
-
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
-
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
-
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:
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)
-
OK I think I've found the root cause of this...
-
Are you also updating Qt for C++20?
:/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
-
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.
-
Are you also updating Qt for C++20?
:/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..
-
Are you also updating Qt for C++20?
:/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?
-
[Even better, any idea where the -Werror comes from?
Of course. dooble.pro
-
even better - then you do'nt have to keep removing it :)
-
Unluckily, another problem which I have a vague feeling you figured out before. Using
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,
[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.
-
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.
-
It did work here, though the trp seems familiar.
I'll reinstall Qt6 tomorrow and see if that helps.
-
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
-
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
[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
-
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
-
Thanks Paul. I also posted it on the OS2World news to see if we get more feedback.
Regards
-
binaries to follow:
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.
-
Only tested to confirm it can build itself.... https://smedley.id.au/tmp/gcc-15.2.0-os2-20250810.zip
-
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
-
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!
-
Thanks for testing KO!
-
Hi Paul,
Did test on some small progs, so far so good :)
Greetz Tellie
-
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
-
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....