Re: Baby X is bor nagain

On 28/06/2024 00:58, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 27/06/2024 21:23, Tim Rentsch wrote:

 

After taking care of all that the build did manage to produce an
executable, which appears to have run successfully.
>
After doing a trial run with the produced executable, I looked at
the tcc man page.  As best I can tell, tcc simply silently
ignores the -fPIC option.

>
I think that it tries to be a drop-in replacement for gcc, so supports
some of its options, even if they don't do anything. Like -O3.
>
Position-independent code seems to be a recent thing with gcc tools. My
tools didn't support it either, until a year ago when I found out about
ASLR.

 gcc has supported generating position independent code for at
over a quarter of a century.

I'm pretty sure that just 4 years ago, I was able to generate non-PIC object files that could be linked with gcc-ld on Windows.
When I tried it last year, it didn't work. So something changed, whether in compiler, or OS loader, where a dynamic image base address, which requires PIC, became the default.

>
For most, PIC isn't a necessity.

 That's your opinion. I don't think it matches reality.

The fact that it hasn't been needed, or been the default, for decades suggests that it isn't a necessity.
A 'necessity' isn't someone arbitrarily decreeing: 'all code must be PIC'.
If you took any Windows EXE and changed some flags in the headers, so loading at the given base address, it would probably still work.

For most applications it doesn't matter and PIC code
works just as well as PDC.

Hang on, isn't that what /I/ said, which you just disagreed with?