On Tue, Oct 13, 2020 at 4:01 PM David Edelson via Gcc <gcc@gcc.gnu.org> wrote: > On Tue, Oct 13, 2020 at 4:09 AM CHIGOT, CLEMENT via Gcc <gcc@gcc.gnu.org> > wrote: > > > > Hi everyone, > > > > Since no one answered, I assume that MULTILIB_REUSE was indeed not the > > solution. > > Thus, I've implemented a solution using a new target macro > > MULTILIB_FALLBACK. > > It allows any target to return a new multilib suffix based on the current > > one being used by the algorithm. This solution is much simpler than > > adding a new Makefile option like MULTILIB_REUSE and it allows targets > > to fully control the new suffix, which can be an advantage. > > > > However, this solution is not perfect. Especially, MULTILIB_FALLBACK must > > take > > care of freeing "curr_multilib_dir" array, which might not be the best > > thing to > > do. But letting "for_each_path" doing it is created a much more complex > > code, > > which isn't better in my opinion. > > > > Anyway, is a patch like the following one seems possible to be integrated or > > should I search for a better solution ? > > Your assumption is completely wrong. The lack of a response has no > bearing on the correctness of the solution. The lack of response is > that this is local to AIX so no one bothers to investigate or respond. > > Thanks, David
Sorry if I offense anyone, it wasn't wanted... What I want to say is that all my attempts with MULTILIB_REUSE were a failure and as noone says that it should work in a certain way, I'm proposing a different approach. Even if for now it's impacting only AIX because of the new FAT library support, I imagine that some other targets might be interested of having a way to fallback on a different multilib at runtime. That's why I tried to make something which can be reusable easily by the way. Clément
