Jonas Maebe via fpc-devel <fpc-devel-pd4fty7x32k2wbthl531ywd2fqjk+...@public.gmane.org> writes:
> On 23/11/2021 17:17, Sergey Organov via fpc-devel wrote: >> Because it was not expected. I definitely can't point to any other user >> tool that, being installed in/opt/cross/bla-bla-bla/, would read >> configuration file from/etc/. Maybe I just didn't meet one yet. >> However, GCC, being most close to FPC by its application, definitely >> doesn't behave like that. > > I think the GCC behaviour is at least partly because of historical > reasons. GCC is often built as part of the sysroot itself, and > originally didn't even have custom sysroot support and instead > hardcoded all the paths in the binary. GCC is also often built without > support for > all target OSes, which means you could get compiler binary name conflicts. > > FPC, OTOH, was designed from the start with as few differences as > possible between native and cross-compiling. Our configuration files > have macro support to deal with this, the compiler binaries by default > always support all target OSes, and we have sysroot support (although > we didn't have it from start, but initially we had hacks like the > earlier mentioned -Xd in combination with -Fl). > > As an aside, on e.g. macOS the -XR parameter is used to point FPC to a > specific macOS SDK. As these are shipped by Apple, they (obviously) > don't contain any FPC-specific files, configuration or otherwise. Fine, you've got your minds set already about it, and I've got my work-around in the form of -n option to get GCC-alike behavior, so everybody's happy! I think you probably still need a fix for globbing of library paths though, at least maybe issue a warning or error, provided full-featured shell-like globbing is not feasible to implement. Thanks, -- Sergey Organov _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
