~/.local/share/Steam/ubuntu12_32/steam has a symbol with a weird
binding type part way through its symbol table:

46 [OBJECT   LOOS/GNU_UNIQUE] size: 0 (0)_ZNSs4_Rep20_S_empty_rep_storageE 0000 (nil)

but we can't just stop there, because there are symbols after it that
need relocating.

I blame C++.

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

These are the same ones special-cased by Flatpak, although Flatpak
would generate a minimal /etc/passwd and /etc/group rather than using
the ones from the host system.

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

libOpenGL can be combined with libGLX (to get approximately the
equivalent of the legacy libGL), or with libEGL.

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Mesa maintainer Emil Velikov informs me that both apps/games and the
graphics driver are allowed to use libgbm, at least on Mesa systems,
so we will need to encapsulate it.

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

This avoids reinventing it.

Signed-off-by: Simon McVittie <smcv@collabora.com>

The cast that hid the change of the void * parameter to a concrete type
masked the bug that we were returning an int-sized integer, not a
pointer-sized integer. Because we only support little-endian platforms
so far, we seem to have got away with it.

Signed-off-by: Simon McVittie <smcv@collabora.com>

As well as detecting truncation and maybe some corner-case overflows,
this fixes a long-standing TODO item: capsule-version with prefix
set to "/" no longer outputs a path starting with //lib or //usr/lib.

Signed-off-by: Simon McVittie <smcv@collabora.com>

This seemed easier than fixing the corner cases individually.

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

As in the previous commit, it seems unnecessarily confusing to have
prefix.path (when interpreted as a C string) not be the path of the
prefix.

Signed-off-by: Simon McVittie <smcv@collabora.com>

Previously, we'd write /etc/ld.so.cache into prefix.path[prefix.len:]:

    /host/etc/ld.so.cache\0\0...
    |<->||<------------>|
     len   temporarily used

and delete it again later with sanitise_ldlibs(). But that seems
unnecessarily confusing: the contents of prefix.path when interpreted
as an ordinary \0-terminated C string are sometimes the prefix, but
sometimes edited in-place to be the name of a file within the prefix.

Signed-off-by: Simon McVittie <smcv@collabora.com>

This makes it a little simpler to reason about.

Signed-off-by: Simon McVittie <smcv@collabora.com>

We were opening the correct ld.so.cache here (in both cases), but then
calling ld_cache_open() which would close the fd we just opened and
open libs->prefix.path instead. In the case where the prefix is set
to "" we would open whatever arbitrary string happened to have been
left in libs->prefix.path last time we used it as scratch space.

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

This is exactly what sanitise_ldlibs() does.

Signed-off-by: Simon McVittie <smcv@collabora.com>

For some reason if the function is named _exactly_ capsule_shim_dlopen
then in this codebase gtk-doc loses track of all function arguments
(for this doc-comment). Re-ordering the doc-comment so that the
Returns item is directly after the argument declarations seems to
fix this.

The symtab address may or may not have been adjusted by the runtime
linker after being mapped into memory, so we need to use fix_addr to
make sure we don't try to deref an offset instead of the actual address.