Hi Raphaël, On Mon, Jan 02, 2017 at 05:37:06PM +0100, Raphael Hertzog wrote: > Can't you just install "binutils-multiarch" when you build such cross > compilers?
No, because using binutils-multiarch is broken. Whenever a new architecture is brought up, binutils-multiarch lacks support for it. I've had enough pain with it already and am actively working on removing users (not the package itself). > That would let us use objdump to inspect any library and let > dpkg-shlibdeps figure out whether it's a library of the correct > architecture or not. Inspecting those objects is a bug in the first place. You are trying to work around it again rather than fixing it properly. I admit that it is non-trivial to fix as it is deeply rooted in glibc. dpkg-shlibdeps inherits it by parsing /etc/ld.so.conf.d. > Please consider the suggestion above before going down that route. We No. > could also make the error non-fatal and ignore .so files that objdump > can't parse. But I would prefer using binutils-multiarch because it would > be bad to ignore failures that mean something else than "file format not > recognized". We could also stop working around problems and start fixing the mess instead. I'm working on it, but progress is slow as I want stuff not to regress. If avoiding regressions is not a priority I can go way faster. E.g. moving /usr/include/stdio.h to a multiarch path. What do you think? Should we just do it and let stuff break? How bad can it be? People probably won't notice until 6 months later, right? I say let's go back to what worked and fix this properly. Why are you backing off now? You did agree on reverting it on regressions earlier. Now there is a regression. How much more crystal clear could it be? Helmut
