On 05/03/2017 12:41 AM, Albert van der Horst wrote: > This message is slightly misleading. In fact the binary is not linked at all, > nor does it need any linking. > > This is the build command for lina > > fasm lina.fas -m256000
Well, I would argue that a compile copying everything together into a huge assembly file and then using an assembler to create a binary is semantically not really different from having the linker copy object code together when statically linking. So I would in fact argue that you're indeed statically linking here. (And any ELF binary that doesn't import any shared object is considered statically linked according to the ELF standard, even if you just compiled an assembly file.) > It seems appropriate to add an override but I've no clue how to do that. If the compiler for Forth works that way, then yes, you should add an override. IIRC the Go language also uses static linking only, so there's precedent for programming languages that only support static linking. To add an override: if you're using debhelper for packaging, just add a file debian/lina.lintian-overrides with the following contents: # Comment explaining the situation lina: statically-linked-binary (If you're using the autoamtic dh(1), then you're set; if you are manually invoking dh_*, then you need to make sure that dh_lintian is present in the right place in debian/rules. If you're not using debhelper, just make sure that that file is installed into /usr/share/lintian/overrides/lina in the binary package.) > There are more requirements in the policy that fail on such simple programs: > Supposedly programs must be made simpler by using strip, however an attempt > to make lina simpler make its brains fall out: > > ~/PROJECT/ciforth$ strip lina > ~/PROJECT/ciforth$ lina > Segmentation fault > > (I don't think strip should behave like this on a valid elf-executable.). If strip removes things that make the program fail, then I believe you're binary is broken in some way and your ELF file is not completely "valid". It might be good enough so that it runs (for statically linked executables the kernel just loads the binary and calls the entry point, so the rest of the ELF format doesn't really matter at all, you could probably get away with a _lot_ of invalid things in the file and it would still run), but there's something in there that doesn't follow the specification, or the code makes certain assumptions that just aren't true in general. For now it's probably fine to skip the 'strip' step (I guess that you probably won't have debug symbols in there anyway?), but I do believe that this really is a bug in your package, not a bug in binutils. The severity of the bug is probably only 'normal' though. Regards, Christian
