I would agree with Martin; I think it's a very good practice for
source files to have an error or not define a function instead of
defining a function that can't possibly work and letting the build
proceed with a broken function. Compiler and linker errors are much
easier to figure out than segmentation faults.
If you try to do it with autoconf, it's easy for the autoconf layer to
get out of sync with the rest of the source code, or for someone to
decide they want to use their own build system instead of the autoconf
layer. And it won't help very much when porting to a new architecture
like Martin said.
On Sun, Aug 6, 2017 at 3:37 AM, Martin Storsjö <mar...@martin.st> wrote:
> On Sun, 6 Aug 2017, JonY via Mingw-w64-public wrote:
>> On 08/05/2017 09:14 PM, Martin Storsjö wrote:
>>> This helps finding unimplemented functions; otherwise the symbol
>>> will exist, but won't contain any implementation, so the function
>>> will end up pointing at whatever other function the linker places
>> I would prefer these checks be in the autoconfigury layer where:
>> ...blah blah test...
>> [arm32], [AC_DEFINE(USE_ARM32_MATH)],
>> [arm64], [...]
>> [AC_MSG_ERROR([Unsupported platform])
>> That way, we don't need to keep growing the if/else macros as more
>> platforms are added.
>> Consider also using AM_CONDITIONAL and other automake constructs if
>> they're separate files to be compiled.
> I'm not sure I think this is somthing that would help with the issue I'm
> trying to address here - I think that kinda misses the point.
> We already have things similar to that; we have a custom list of files to
> build into libmingwex.a for each of the 4 architectures, so if desired, we
> could easily split these assembly files into one for each architecture as
> Currently there's code for x86 (32 and 64 bit) and 32 bit arm in the same
> file. The consistent next step would be to add 64 bit arm into the same (see
> patch 09/19) - in most cases, it's just a few 2-5 instruction snippets so
> it's much less overhead to add to the same file instead of creating
> completely new ones. If you want to, we could also split them into separate
> files for each architecture.
> Currently, these source files are under this heading in Makefile.am:
> # These mingwex sources are target independent:
> crt/dllentry.c crt/dllmain.c \
> Having configure error out if you build for a new unsupported architecture,
> would help a user trying to build for another new, unsupported architecture,
> to know that it's pointless to proceed.
> However, if you're the one trying to implement support for that new
> architecture, the first thing you'd need to do is to update configure.ac and
> add the new architecture to the list of "supported" ones, in order to even
> configure the build. And then what?
> Then you need to provide all the necessary functions for the platform. In
> order to do that, you'd most probably start off with the source files for
> one of the existing architectures (in my case, I took the list of source
> files for arm32), read each and every one of the files manually and see
> which of them need customizations for the new arch.
> The "read each file manually" step is something I think most programmers
> would avoid and just go ahead and try compiling things - that's what I did.
> I took the list of source files for arm32 and tried building for arm64, and
> fixed issues until it all built without errors and mostly without warnings.
> Some files would have an explicit #error that's easy to spot, and fix. Some
> files would implicitly try building e.g. x86 assembly, and fail.
> For some other case, you might have a function completely missing, which
> you'd notice when you try to link an app that uses that function.
> But the deal with these assembly file, that is so devious, is that it
> assembles without error, and it even defines the symbol, but without
> actually producing any code. If I had gotten linker errors about missing
> symbols, or assembler errors or preprocessor errors, it would have been
> obvious to spot the issue.
> On the other hand, I see almost all other asm files also have the same
> issue. The other ones (stdio/scanf*.S) I had already noticed, since the rest
> of the associated code clearly errored out and pointed out all of those
> functions to me.
> // Martin
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> Mingw-w64-public mailing list
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Mingw-w64-public mailing list