Bug#880771: libdwarf/dwarfdump cross compile
On 03/27/2018 09:34 PM, Helmut Grohne wrote: > I suggest that resend your previous mail after carefully checking each > of the words "build", "host", and "target" against their definitions > (and telling which definition you used unless you use GNU terminology). Ah. Thanks. That I can do. And I will inspect the wording in the project source code for those words in the likely case I've used them incorrectly somewhere. Thanks for repeating that link to Configure Terms and History. DavidA. -- I don't understand where I ever had time to go to work for 40 hours a week. -- Bill Cheswick in ;login:
Bug#880771: libdwarf/dwarfdump cross compile
On Tue, Mar 27, 2018 at 05:10:14PM -0700, David Anderson wrote: > On 03/26/2018 09:26 PM, Helmut Grohne wrote: > > Cool. Before we continue, could you do a brief terminology check? Both > > autotols and Debian (dpkg) use GNU terminology[1] for build/host/target. > > This notably differs from mozilla terminology and tends to cause > > confusion. Please stick with GNU terminology, because it is the one that > > autotools use and it is more expressive than mozilla terminology. > > I would appreciate some more-specific terminology guidance. I added a link explaining it in very much detail to my last mail. It tries to clarify the wors "build", "host" and "target". Do you have a specific question. It was this link: https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html Another explanation can be found in man dpkg-architecture on Debian systems. > I don't understand mozilla terminology...either. That can be a good thing as you can avoid confusion by not looking at mozilla's terminology. > Where have I gone wrong? Point out an example or two? It's that this is not obvious. For example, your remark about AC_TRY_COMPILE can either mean that something went very wrong for you or that you were incorrectly using "build" there. Then you said "target library". Either you confused it with "host library" or elfutils is more complex than I thought and it is target-dependent (very unusual, but possible in this case). I expected that "target" would be irrelevant for dwarfutils. So what you wrote makes little sense to me and it is far from obvious which part might be wrong, if any. I suggest that resend your previous mail after carefully checking each of the words "build", "host", and "target" against their definitions (and telling which definition you used unless you use GNU terminology). Helmut
Bug#880771: libdwarf/dwarfdump cross compile
On 03/26/2018 09:26 PM, Helmut Grohne wrote: > Cool. Before we continue, could you do a brief terminology check? Both > autotols and Debian (dpkg) use GNU terminology[1] for build/host/target. > This notably differs from mozilla terminology and tends to cause > confusion. Please stick with GNU terminology, because it is the one that > autotools use and it is more expressive than mozilla terminology. I would appreciate some more-specific terminology guidance. I don't understand mozilla terminology...either. Where have I gone wrong? Point out an example or two? > >> Tested with --host=gcc-arm-linux-gnueabihf > This is not a supported host architecture for Debian. Oops. From README just updated to what I actually did: ./configure --host=arm-linux-gnueabihf DavidA. -- I don't understand where I ever had time to go to work for 40 hours a week. -- Bill Cheswick in ;login:
Bug#880771: libdwarf/dwarfdump cross compile
Control: tags -1 + fixed-upstream On Tue, Mar 27, 2018 at 10:02:25AM -0700, David Anderson wrote: > code/dwarfdump/configure and code/libdwarf/configure > now support cross building. see code/README. That's good to hear. Thank you very much for the effort you put into this!
Bug#880771: libdwarf/dwarfdump cross compile
code/dwarfdump/configure and code/libdwarf/configure now support cross building. see code/README. I'm sure I've got something wrong or misunderstood, but it does seem to work. Let me know what needs fixing. I copied the resulting arm dwarfdump to an arm linux machine and it worked, dumping its own DWARF sections. Which is a testament to the great work done by debian/ubuntu/GNU folks. text from README: For example, on Xubuntu 16.04 x86_64 the following works. cd code sudo apt-get install gcc-arm-linux-gnueabihf Now ensure libelf.h libelf.a or .so is in the gcc-arm-linux-gnueabihf tree in the correct places. If the build machine has zlib (aka libz) but the arm tree does not the --disable-libz should work to enable building. If the build and arm trees both have libelf and libz then remove the --disable-libz. Neither libz nor libelf are installed automatically in the arm tree. cd libdwarf ./configure --host=--host=arm-linux-gnueabihf --disable-libz make cd ../dwarfdump ./configure --host=--host=arm-linux-gnueabihf --disable-libz make David Anderson -- ...the Linux philosophy is "laugh in the face of danger". Oops. Wrong one. "Do it yourself". That's it. -- Linus Torvalds
Bug#880771: libdwarf/dwarfdump cross compile
Hi David, On Mon, Mar 26, 2018 at 01:28:53PM -0700, David Anderson wrote: > I figured out a simple way to cross-build while > completely separating build-time objects from target > objects. Using AC_PATH_PROG as Helmut suggested. > > Nothing complicated about it. Simple 'make'. Cool. Before we continue, could you do a brief terminology check? Both autotols and Debian (dpkg) use GNU terminology[1] for build/host/target. This notably differs from mozilla terminology and tends to cause confusion. Please stick with GNU terminology, because it is the one that autotools use and it is more expressive than mozilla terminology. > Tested with --host=gcc-arm-linux-gnueabihf This is not a supported host architecture for Debian. It's the cross compiler package name. The value to pass to --host should be just arm-linux-gnueabihf. > which generates libdwarf as arm fine, but > the dwarfdump final link fails because > AC_TRY_COMPILE looks for -lz and looks > in the build machine location, not the cross area. If AC_TRY_COMPILE checks build aspects rather than host aspects, something is seriously wrong. You likely need to check for a bad CC variable or like that in config.status. > Because the cross area does not have -lz, > while the build environment does I need > to find out at build time about > that target library. If you need a libz for arm, you need to install it of course. You can install regular arm packages on your amd64 machine. For doing so, you enable armhf as an foreign architecture (dpkg --add-architecture armhf), update your package cache and install zlib1g-dev:armhf. > I'm not sure how to fix this part, cannot > find anything on the web but words admitting it is > a problem. If all else fails, we can simply wait for Fabian to upload your changes (even if that takes months). When doing so he'll close this bug, which triggers a test rebuild on my cross buildd (and has done so previously, the process works!) and will likely result in me sending patches again. I have still plenty (like 1) packages to fix. ;) Thus I aim for throughput, not low latency. > Any suggestions to detect -lz in the target > libraries? There are too many strange aspects above to say something useful. Maybe I can say more after addressing those points. Helmut [1] https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html
Bug#880771: libdwarf/dwarfdump cross compile
I figured out a simple way to cross-build while completely separating build-time objects from target objects. Using AC_PATH_PROG as Helmut suggested. Nothing complicated about it. Simple 'make'. Tested with --host=gcc-arm-linux-gnueabihf which generates libdwarf as arm fine, but the dwarfdump final link fails because AC_TRY_COMPILE looks for -lz and looks in the build machine location, not the cross area. Because the cross area does not have -lz, while the build environment does I need to find out at build time about that target library. I'm not sure how to fix this part, cannot find anything on the web but words admitting it is a problem. Pushed this stuff to sourceforge so it at least actually builds libdwarf and gets dwarfdump objects built though the final link fails on the -lz issue. Any suggestions to detect -lz in the target libraries? David Anderson
