1.18.2: LTO exposes code issues #544
Comments
kloczek
changed the title
|
I really have no idea about what kind of cobsts you are talking about. |
yes, but to do that you need automake, autoconf and libtool installed, one of which requires perl5 plus GNU m4 and a variety of fragile shell scripts. also libtool is unmaintained since years and very buggy, and it goes to great length to make a user's life harder by removing explicitly passed flags such as -static and replacing -lfoo parameters with a hardcoded location to a .so file, extracted from .la files. with vanilla libtool it's practically impossible to do a proper crosscompile and static builds. as far as the build warnings are concerned, you may have found a real issue though. |
|
You don''t need to maintain all those components. They are coming with your favourite distribution. Ahat actually is more important management features when you are using exact tooling. From that point of view am/ac/lt/pkgconfig still is unbitable. Next would be probably meson than cmake. am/ac/lt rocks and all is working. Adding coverity, fuzzler or any other code scanner support is almost transparent. Many other macros adding more tooling features are ready to use. |
|
From time to time we have requests like this - support autotools, support cmake, support Visual Studio 20?? project files etc. Some of them even come with more-or-less working build scripts/files. Trouble is that all those contributors expect that somebody will take care of "their" build files in the future. Which usually does not mean near future but sooner or later we add, remove, rename or shuffle source files or make some significant change in macros/defines used at build-time and it is exactly the point when the original contributor is gone and we have to pay the maintenance cost. The statement |
|
Generally there is no any obstacles to have in single tree support for all of those build tooling. You can even keep still all your Makefile files if you want without introducing conflicts.
If you are not working on whole OS distribution (like I'm) that statement is true. |
|
IIRC the code in question also triggers some warnings in Regarding autotools... there exists already a cmake branch which only requires a rebase and some polishing, would that also be acceptable? |
i did take a look but the code is quite hard to follow, involving a lot of variables/conditions. i guess the best/easiest way to figure out when an out-of-bounds write can occur is to single-step through the code and inspect the values, or use a static analyzer such as frama-c which gives quite useful informations for code like this. |
BTW: would you accept PR with automake/autoconf and libtool based build framework (with use pkgconfig to detects libtommath)
The text was updated successfully, but these errors were encountered: