OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Applications => Topic started by: Neil Waldhauer on March 08, 2022, 03:09:32 am
-
I'm interested in finding GFortran. All I've found so far is an emx-based build from 1999 on Hobbes.
https://hobbes.nmsu.edu/?path=%2Fpub%2Fos2%2Fdev%2Femx%2Fcontrib%2Fg77
-
Hey Neil - some of my gcc builds include gfortran - not really tested but it builds :)
-
This one has gfortran.exe included.
https://smedley.id.au/downloads/gcc-8.3.0-os2-20190324.zip (https://smedley.id.au/downloads/gcc-8.3.0-os2-20190324.zip)
I set up the environment, and gfortran executes
/* my command file to set up the GCC 8.3.0 environment */
GCCDir = 'f:\programs\gcc830\usr'
GCCDir2 = translate(GCCDir, '/', '\')
ToolkitDir = 'f:\programs\os2tk45'
ToolkitDir2 = translate(ToolkitDir, '/', '\')
localName = 'local830'
localCPU = 'i686-pc-os2-emx'
localVer = ''localVer''
'set PATH='GCCDir'\'localName'\bin;'GCCDir'\'localName'\libexec\gcc\'localCPU'\'localVer';%path%'
'set C_INCLUDE_PATH='GCCDir2'/'localName'/lib/gcc/'localCPU'/'localVer'/include;'ToolkitDir2'/H;'
'set CPLUS_INCLUDE_PATH='GCCDir2'/'localName'/include/c++/'localVer';'GCCDir2'/'localName'/include/c++/'localVer'/'localCPU';'GCCDir2'/'localName'/lib/gcc/'localCPU'/'localVer'/include;'GCCDir2'/'localName'/include/c++/'localVer'/backward;'GCCDir2'/'localName'/include;'
'set LIBRARY_PATH='GCCDir2'/'localName'/lib/gcc/'localCPU'/'localVer';'GCCDir2'/'localName'/lib;'
'set BEGINLIBPATH='GCCDir'\'localName'\lib;'
But I'm not getting a good compile for hello world.
hello.for
--------
print *, "Hello, world"
end
{0} gfortran hello.for
hello.for:1:1:
print *, "Hello, world"
1
Error: Non-numeric character in statement label at (1)
hello.for:1:1:
print *, "Hello, world"
1
Error: Unclassifiable statement at (1)
hello.for:2:1:
end
1
Error: Non-numeric character in statement label at (1)
hello.for:2:1:
end
1
-
I don't know if this helps, but fortan is include in Open Watcom.
-
Thought I'd try as I have various versions of Paul's GCC installed. Named the hello world program hello.f90 as suggested at https://riptutorial.com/fortran/example/3044/hello--world (https://riptutorial.com/fortran/example/3044/hello--world) (suffix might be important) and used this command line,
gfortran -o hello.exe hello.f90
Works with GCC 4.4.6, 5.3.0 required gcc530.dll to run and all newer fail like,
[H:\tmp\r]gfortran -o hello.exe hello.f90
../.././libbacktrace/mmap.c:190 (K:/USR/local620/lib/gfortran.a(mmap.o)): Undefined symbol _munmap referenced from text segment
../.././libbacktrace/mmap.c:145 (K:/USR/local620/lib/gfortran.a(mmap.o)): Undefined symbol _mmap referenced from text segment
No GCC 8.3.0 installed but 6.2.0, 7.1.0 and 9.1.0 all failed with same mmap error. 5.5.0 is missing gfortran.
Attempting to build with -lcx, which would fix things with gcc and g++ didn't help and quickly reading the documentation doesn't show how to link to libcx.
So gcc530 is the newest version that simply works here, at least with gcc530.dll on the LIBPATH.
For my environment, I unzip to @unixroot\usr so k:\usr\local530 etc and use the attached cmd file, installed in @unixroot\usr\bin. To change which GCC it sets up, change the name and edit line 73 the part that says 'gcc530'. Thanks to KOMH for the cmd file, I have multiple ones,
[K:\usr\bin]dir gcc*env.cmd
The volume label in drive K is Unixroot.
The Volume Serial Number is 2CFE:A5C0.
Directory of K:\usr\bin
3-23-19 7:59p 13,349 13,555 a--- gcc446env.cmd
4-01-18 11:01p 13,349 124 a--- gcc510env.cmd
6-10-18 11:10p 13,349 13,555 a--- gcc530env.cmd
6-11-18 7:22a 13,349 13,555 a--- gcc550env.cmd
11-26-18 5:03p 13,349 13,555 a--- gcc620env.cmd
11-26-18 5:03p 13,381 13,555 a--- gcc710env.cmd
5-05-19 10:41a 13,381 13,555 a--- gcc910env.cmd
7 file(s) 93,507 bytes used
Edit: Actually attach cmd file
-
Thanks for testing Dave - I might try re-enabling it with GCC 9.3.0
-
With GCC 9.1.0, this command line works here,
[H:\tmp\r]gfortran -Zomf -Xlinker 'k:/usr/lib/libcx0.lib' -o hello.exe hello.f90
[H:\tmp\r]hello
Hello world!
I'd assume it works with other versions.
I notice that gfortran doesn't seem to support the -Zlinker option.
-
More portable,
[H:\tmp\r]gfortran -Zomf -Xlinker '/@unixroot/usr/lib/libcx0.lib' -o hello.exe hello.f90
[H:\tmp\r]hello
Hello world!
hello.exe is quite big,
3-12-22 8:19p 509,299 0 a--- hello.exe
Edit, adding -Zmap to the compile line and then doing "mapxqs hello.map" will produce more informative trp reports if the program crashes.
-
Building gcc 9.4.0 now. Will see if I can avoid the need to add xlinker :)
-
Building gcc 9.4.0 now. Will see if I can avoid the need to add xlinker :)
OTOH, linking against libcx does have benefits such as exceptq support I believe and looking at the map file, some other functions are pulled in from libcx0.
-
Building gcc 9.4.0 now. Will see if I can avoid the need to add xlinker :)
OTOH, linking against libcx does have benefits such as exceptq support I believe and looking at the map file, some other functions are pulled in from libcx0.
I was more thinking that if things like mmap are unavoidable,then I'd automate dragging in libcx :)
-
I was more thinking that if things like mmap are unavoidable,then I'd automate dragging in libcx :)
OK, that was going to be my suggestion.
-
I'm trying gcc830 with the .f90 suffix, and that does help.
{0} gfortran -Zomf -Xlinker '/@unixroot/usr/lib/libcx0.lib' -o hello.exe hello.f90
emxomfld: _abspath failed on 'crt0.obj'!!!
-
I'm trying gcc830 with the .f90 suffix, and that does help.
{0} gfortran -Zomf -Xlinker '/@unixroot/usr/lib/libcx0.lib' -o hello.exe hello.f90
emxomfld: _abspath failed on 'crt0.obj'!!!
crt0.obj comes as part of the original klibc dev environment - probably also in rpm?
-
I'm trying gcc830 with the .f90 suffix, and that does help.
{0} gfortran -Zomf -Xlinker '/@unixroot/usr/lib/libcx0.lib' -o hello.exe hello.f90
emxomfld: _abspath failed on 'crt0.obj'!!!
Sounds like an environment problem. crt0.obj should be in /@unixroot/usr/lib
-
[U:\DEV]gcc --version
gcc (GCC) 9.4.0
Copyright (C) 2019 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.
[U:\DEV]gfortran hello.f90 -o hello.exe
[U:\DEV]hello
Hello, World!
Binaries tomorrow after a bit more testing....
-
Environments are hard to set up.
If I add f:/usr/lib to LIBRARY_PATH, then the error becomes
{0}[d:\neil\neil\coding\fortran] gfortran hello.f90
../.././libbacktrace/mmap.c:212 (f:/programs/gcc830/usr/local830/lib/gfortran.a(mmap.o)): Undefined symbol _munmap referenced from text segment
../.././libbacktrace/mmap.c:167 (f:/programs/gcc830/usr/local830/lib/gfortran.a(mmap.o)): Undefined symbol _mmap referenced from text segment
And sure enough, a huge gfortran.a has appeared in the lib directory.
-
it's interesting, compiling seems somewhat broken without the -Zomf, even adding "-Xlinker '/@unixroot/usr/lib/libcx0.a'" I get the mmap symbol failures and the huge static lib in the lib directory. Perhaps a fault with ld.exe.
Anyways it is usually encouraged to use -Zomf with the GCC toolchain, which leads to using the system linker (usually wlink now a days) to link. Our ld is ancient, GPL v1 with RMS as principal author and basically just uses emxbind to graft on the executable part to an aout object.
Looks like Paul has fixed/worked around the issues with mmap anyways.
-
https://smedley.id.au/tmp/gcc-9.4.0-os2-20220314.zip
It builds itself which is the only testing done thus far. No gccenv.cmd included - it's expected/assumed you know what you're doing if you're downloading this.
-
Seems to work. No sign of mmap, did you just eliminate it?
I'll try building SeaMonkey with it next.
-
Hi Dave,
Seems to work. No sign of mmap, did you just eliminate it?
I'll try building SeaMonkey with it next.
Yeah - I modified configure for libbacktrace to not use mmap. I'll try building a few more things with it too..
Cheers,
Paul
-
It failed to link xul.dll here, likely a pipe issue. The linking stage pipes almost a thousand obj files to emxomfld and if IIRC, the issue with the Bitwise build was recursive piping.
I believe it was fixed in https://github.com/bitwiseworks/gcc-os2/issues/14 (https://github.com/bitwiseworks/gcc-os2/issues/14)
-
Hey Dave,
It failed to link xul.dll here, likely a pipe issue. The linking stage pipes almost a thousand obj files to emxomfld and if IIRC, the issue with the Bitwise build was recursive piping.
I believe it was fixed in https://github.com/bitwiseworks/gcc-os2/issues/14 (https://github.com/bitwiseworks/gcc-os2/issues/14)
I'll look into applying the diffs from that ticket.
Edit: https://smedley.id.au/tmp/gcc-9.4.0-os2-20220314b.zip has the diffs from the above ticket included.
Cheers,
Paul
(Ian fixed URL)
-
...and if you're feeling adventurous.... https://smedley.id.au/tmp/gcc-10.3.0-os2-20220314.zip
-
Edit: https://smedley.id.au/tmp/gcc-9.4.0-os2-20220314b.zip has the diffs from the above ticket included.
Cheers,
Paul
(Ian fixed URL)
I tried gcc-9.4.0... and it works for hello world. The executable for hello world is 1.4 MB, but it works.
-
Hi Paul, still not linking xul.dll. Looking closer, I can't see any problem though there must be. Comparing to a 992 cmd line with diff -u, it shows,
--- cmd_992 2022-03-14 23:13:36.000000000 -0700
+++ cmd_994 2022-03-14 23:35:56.000000000 -0700
@@ -391,4 +391,4 @@
-pthread
-lglib-2.0
-lintl
--lcairo
+-lcairo
\ No newline at end of file
I probably added the newline to 992 while copy and pasting. It's weird, looking at the hex shows no difference in the -lcairo, I'll have to look more tomorrow.
-
Hi Dave,
Hi Paul, still not linking xul.dll. Looking closer, I can't see any problem though there must be. Comparing to a 992 cmd line with diff -u, it shows,
--- cmd_992 2022-03-14 23:13:36.000000000 -0700
+++ cmd_994 2022-03-14 23:35:56.000000000 -0700
@@ -391,4 +391,4 @@
-pthread
-lglib-2.0
-lintl
--lcairo
+-lcairo
\ No newline at end of file
I probably added the newline to 992 while copy and pasting. It's weird, looking at the hex shows no difference in the -lcairo, I'll have to look more tomorrow.
Can you share the XUL error? Perhaps there are additional diffs from the bww code that I'm missing?
-
Edit: https://smedley.id.au/tmp/gcc-9.4.0-os2-20220314b.zip has the diffs from the above ticket included.
Cheers,
Paul
(Ian fixed URL)
I tried gcc-9.4.0... and it works for hello world. The executable for hello world is 1.4 MB, but it works.
With GCC 11.2.0 and:
gfortran -Zomf -Zmap hello.f90 -o hello.exe
it's 519,625 bytes, which after lxlite is 123,397
Cheers,
Paul
-
I've got some kind of mis-configuration
{0} gfortran -Zomf -Zmap hello.f90 -o hello.exe
ilink.exe: No such file or directory
-
Hi Dave,
Hi Paul, still not linking xul.dll. Looking closer, I can't see any problem though there must be. Comparing to a 992 cmd line with diff -u, it shows,
--- cmd_992 2022-03-14 23:13:36.000000000 -0700
+++ cmd_994 2022-03-14 23:35:56.000000000 -0700
@@ -391,4 +391,4 @@
-pthread
-lglib-2.0
-lintl
--lcairo
+-lcairo
\ No newline at end of file
I probably added the newline to 992 while copy and pasting. It's weird, looking at the hex shows no difference in the -lcairo, I'll have to look more tomorrow.
Can you share the XUL error? Perhaps there are additional diffs from the bww code that I'm missing?
-
I ran the 940 command to build xul in the 920 obj dir, it worked but produced an xul.dll of only 73.5 MB's instead of the usual 461MB's. Testing, it does work.
I'll have to reboot (obj dir is locked) and try the opposite
-
Doing the opposite results in the same failure. Not sure what the problem is, possibilities include a bad static lib, a bad list of obj files or something to do with coming up with the exports list for xul.
The build deconstructs static libs to object files and the export list is produced with some magic involving the stabs info.
-
GCC 11.2.0 for testing....https://smedley.id.au/tmp/gcc-11.2.0-os2-20220316.zip
Essentially the same patches as the 9.4.0 and 10.3.0 builds...
-
I've got some kind of mis-configuration
{0} gfortran -Zomf -Zmap hello.f90 -o hello.exe
ilink.exe: No such file or directory
Seems you don't have ilink.exe the system path.You're better off with wlink anyway, but need:
set EMXOMFLD_TYPE=WLINK
set EMXOMFLD_LINKER=wl.exe
in you're environment, and of course, a copy of wl.exe
Cheers,
Paul
-
Yes, that was it. Hello.exe now builds under GCC940 and is about 500 K. :)