libtool: Workaround for issue on clang64 and some debug code. Clang warns a…

[JPeterMugaas]

…nd will sometimes generate an error if the format string is not not a litteral constant ( -Wformat-nonliteral ). That causes some packages to fail to compile. Note that this warning is correct but I consider it harmless in libtool since it is used by libraries for testing and debuggng. libtool really should be properly fixed for this.

[jeremyd2019]

I would suggest instead declaring it with __attribute__ ((format (printf, 3, 4))) and that will then push the format string warning/error onto the caller, where it rightly should be

[JPeterMugaas]

Okay. I tried it but gives me syntax errors or something out of range. I do NOT want to mess with that I don't understand and will probably get wrong. I've seen things like 1,2 or 3,4. I don't know.

My solution in pushing the diagnostic settings, ignoring the warning, popping the diagnostic settings in isolated procedures seems to be the most elegant solution that works when compiling stuff that uses libtool. It is a warning but there is something that makes the warning an error.

[lazka]

Which packages are affected by this problem?

[JPeterMugaas]

I was working on an improved lasem package when I noticed the issue.

msys2/MINGW-packages#9514

I was working on lasem so that I could build ruby-mathematical since that would be required for something that can generate OpenCL documentation in PDF format.

and the msys patch is a companion to a pull request I made at:

msys2/MINGW-packages#9496

The problem is that libtool bash script creates code and even a program where a string is being passed to a format function. That causes an error when compiling lasem with clang64 because it's treated as an error instead of a warning.

Both libtool and lasem seem to be relatively unmaintained and they probably did not anticipate what would happen with clang. Unfortunately, there still may be stuff that depends upon these things. I'm working under a less than ideal situation.