[csw-maintainers] assembler in shared libraries

[Peter FELECAN]

James Lee <james at opencsw.org> writes:

> On 02/06/09, 22:19:19, Dagobert Michelsen <dam at opencsw.org> wrote regarding
> Re: [csw-maintainers] assembler in shared libraries:
>
>> > --- brutal kludge --- to use explicitly gld on i386, thus having the
>> > best performance for the platform; for sparc, the project doesn't have
>> > assembler crafted code.
>
>> Thanks for your effort, I have a similar problem with libgmp, which
>> also has assembler optimizations for x86.
>
> Are you doing this because you believe it's better or because you
> proved it's better?
>
> I had a similar situation (with mesa3d) and, after fighting to get
> it to compile, the assembler was slower.

As usual, James ask the good question. Trying to answer it by running a
benchmark I discovered that the "brutal kludge" didn't work in a not so
subtle way:

- when linking, without error, with the static library, the execution
  halts with an "illegal instruction" in _rt_boot (real time library:
  using sched_yield, &c).

- when linking with the shared library I get unresolved symbols; after
  exploring the library I conclude that there is a mistake of local
  instead of global for a bunch of symbols.

After that, I repackage a version which didn't use assembler code,
consequently being able to use the system's linker. None of the above
phenomena appears and the benchmark programs ran with success.

Lessons learned:

1. Test thoroughly your package
2. The GNU linker didn't work in some cases --- at least in this one
3. Sacrifice hypothetical gains for usability --- well, mine is an
   extreme case

I'll explore the behaviour of the GNU linker as I have some more
candidates with the issue that I tried to solve initially.
-- 
Peter