[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Static linking question - Bug #859130 ITP: lina -- iso-compliant Forth interpreter and compiler



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


Reply to: