FreeBASIC broken following OS upgrade; generates problematic .asm files...?

[mandian]

Here is how I build:

https://github.com/OpenMandrivaAssociation/FreeBASIC

and as you my see I just apply few trivial patches for fbdoc and fbhelp. Here is the result:

https://file-store.openmandriva.org/api ... ?show=true

The build system uses gcc 13.2.1 while on my test box I used gcc gcc 13 .1.1. If I used '-asm att' on my test box I got the same error as in the build system with gcc 13.2.1:

Code: Select all

/usr/lib64/gcc/x86_64-openmandriva-linux-gnu/13.1.1/../../../../x86_64-openmandriva-linux-gnu/bin/ld: bin/fbc-new: error: PHDR segment not covered by LOAD segment
/usr/lib64/gcc/x86_64-openmandriva-linux-gnu/13.1.1/../../../../x86_64-openmandriva-linux-gnu/bin/ld: warning: bin/fbc-new has a LOAD segment with RWX permissions
make: *** [makefile:735: bin/fbc] Error 1

[coderJeff]

Hmm, the build process looks pretty good.

Was there a version of gcc & binutils that worked in the past?

I'm not sure what to suggest next.

[mandian]

There was something wrong in my spec files. Now it build and works but only on x86_64 arch, I have still some problems with znver1 and aarch64. I suppose it'a matter of path: in fact I have to changed the hard coded path of the library directory

https://github.com/OpenMandrivaAssociat ... .spec#L152

[coderJeff]

in fact I have to changed the hard coded path of the library directory

The 'sed' expression is aggressive. It's going to replace "lib" -> "lib64" even in places where it should not be replaced.

I think I see now (maybe):
- The bootstrap package is partially compiled sources (essentially, making it have pre-configured makefile options)
- But you need the bootstrap source to have been generated with 'ENABLE_LIB64=1'

In original fbc sources:

Code: Select all

	dim libdirname as string = "lib"
	#ifdef ENABLE_LIB64
		if( fbIs64Bit( ) ) then
			libdirname = "lib64"
		end if
	#endif

And from fbc's makefile:

Code: Select all

#   ENABLE_LIB64=1         use prefix/lib64/ instead of prefix/lib/ for 64bit libs (non-standalone only)

Hmm, so either need to produce a different bootstrap package for release, or make this option runtime configurable.

[mandian]

Yes, I know the sed filter is aggressive but there are sic occurrences of "lib" (with quotes) in makefile and I was not sure which I should modify of I used the sed filter as a first attempt and it worked.

So far with your trick I built the bootstrapped fbc for all supported arches in OpenMandriva. I also test some previously version of freebasic I compiled for sure in the past, as 1.05.1, 1.02.1 and 0.90.1, and they only works if I used your trick (and -std=gnu89, without it always fails) so definitively gcc 13 changed something.

Finally I had to forced the use of gcc in place of gcc, which is the default in OpenMandirva, because clang[\i] fails with the bootstrapped fbc code ([i[rtlib[\i] and gfxlib2[\i] are built fine instead):

Code: Select all

/usr/bin/clang -c -Os -fomit-frame-pointer -g3 -gdwarf-4 -Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector-all --param=ssp-buffer-size=4 -m64 -mtune=generic -flto bootstrap/linux-x86_64/fb.c -o bootstrap/linux-x86_64/fb.o
bootstrap/linux-x86_64/fb.c:1499:2: error: indirect goto in function with no address-of-label expressions
 1499 |         goto *vr$5;
      |         ^
bootstrap/linux-x86_64/fb.c:2960:3: error: indirect goto in function with no address-of-label expressions
 2960 |                 goto *vr$42;
      |                 ^
bootstrap/linux-x86_64/fb.c:3327:2: error: indirect goto in function with no address-of-label expressions
 3327 |         goto *vr$114;
      |         ^
3 errors generated.
make: *** [makefile:1406: bootstrap/linux-x86_64/fb.o] Error 1
make: *** Waiting for unfinished jobs....
/usr/bin/clang -c -Os -fomit-frame-pointer -g3 -gdwarf-4 -Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector-all --param=ssp-buffer-size=4 -m64 -mtune=generic -flto bootstrap/linux-x86_64/emit_x86.c -o bootstrap/linux-x86_64/emit_x86.o

[coderJeff]

sed ...

I believe all the other uses for "lib" are for naming output files, e.g. "lib" + "SOMENAME" + ".a", etc. I can see how would seem to work ok when producing an executable only.

so definitively gcc 13 changed something.

Yes, I think default is a newer standard. I'm not sure what the changes in the standard create issues ... I seen this before, but at the moment I can't recall where and why I had to specify a different stdc. I may remember, .. or not, lol.

clang[\i] fails with the bootstrapped fbc code

Actual support for clang has been added only recently to fbc 1.20.0
We added '-gen clang' command option to generate c backend code that is better compatible with clang
tmc included a patch for the indirect goto error in his work when adding the clang support:
https://github.com/freebasic/fbc/commit ... 725cb521d6

I appreciate you sticking with it and trying to get things to work. Sounds like you will probably need the clang addition in fbc 1.20.0 to get bootstrapped with more suitable clang sources.

Which reminds me that I never tagged fbc version 1.10.2, which is already merged to fbc/master and it includes a new makefile option BOOTFBCFLAGS to pass extra options when building the bootstrap distro.

If you wanted to test just the new clang stuff, but not the newest current development:
You could try creating a bootstrap with commit # a40bb40b055d0dac54fb5ee6c6eeb517a1bae553 from fbc/master
You may need to patch the makefile to use '-gen clang' when partial compiling the fbc sources.

If this works for you, maybe we could do a 1.10.3 partial release and post your bootstrap sources.

[mandian]

I have found no way to make it works with clang. I tested both commit a40bb40b055d0dac54fb5ee6c6eeb517a1bae553 and the latest with the same result: it stops at emit_SSE.bas without any explanations.

https://pastebin.com/PdHWLyLn

It worked with gcc (with -std=gnu89 and -asm att tricks), instead.