Hi!
On Fri, 2015-05-15 at 15:03:53 +1200, Michael Hudson-Doyle wrote:
> Package: libdpkg-perl
> Version: 1.17.25ubuntu1
> Severity: normal
>
> I have been working on adding support to the native Go toolchain for shared
> libraries.
Cool! I've long considered languages not supporting shared libraries
to not be very compelling (to put it mildly :).
> Upstream git now produces shared libraries and dpkg-shlibdeps
> complains noisily when processing them:
>
> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record:
> 00000000002884d8 R_X86_64_64 type.func(*launchpad.net/go-xdg/v0.XDGDir)
> []string+0x0000000000000088
> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record:
> 00000000002884f0 R_X86_64_64 type.func(*launchpad.net/go-xdg/v0.XDGDir)
> []string+0x0000000000000090
> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record:
> 0000000000288858 R_X86_64_64 type.func(*launchpad.net/go-xdg/v0.XDGDir)
> []string
> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record:
> 0000000000288940 R_X86_64_64 type.func(*launchpad.net/go-xdg/v0.XDGDir)
> []string
>
> I suppose a few regexp tweaks are required.
This would imply changing the regexes to match on column basis or very
strict amount of spaces, because there are valid cases where a version
node or the visibility markers might or not be present, which seems a
bit more flaky, although I doubt the objdump output format has changed
for a long time, but we'd have to verify that.
In any case, there's several things that come to mind why on first
thought this might seem like not an entirely good idea anyway (w/o
having never actually looked deep into Go in any serious way):
- Is the ABI (for each supported arch) specified as part of the
language, or is it an implementation detail?
+ If the latter, it means this might allow linking incompatible
objects, which is one of the reasons C++ does not specify the
mangling rules.
- Do the symbol names interop with GCC Go?
- How would this handle ABI changes in the future if the symbols are
not mangled?
- How would this handle interop with languages that do not support
spaces? Can you specify to export to a specific language so that
it gets symbols mangled for that? Or do you need something else
like manually specifying the symbols in asm, or something like
FFI?
On Mon, 2015-05-18 at 01:55:57 -0400, Guo Yixuan wrote:
> Package: libdpkg-perl
> Version: 1.17.25
> Followup-For: Bug #785344
>
> It seems that ELF symbol names can contain any characters, except "\0".
> So a correct solution would be read ELF from perl, instead of using the
> output of objdump. (Unless objdump has a -0 option similar to xargs...)
While it's true that those are allowed symbols, as I could not find
anything stating otherwise in the ELF spec, I've to wonder about the
wisdom of that choice? But when handling dpkg issues, my most
conservative side comes afloat, so it might just be that talking here. :)
And Implementing an ELF parser in perl, just to be able to support Go,
does not seem very compelling, no.
> This discussion at golang provides some background:
> https://go-review.googlesource.com/19101
It complains about a session expired and that I need to login, after
ignoring the dialog, I cannot see anything there.
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
