About gprofng/30006 - Failure to build binutils-2.40 gprofng using gold

[Cary Coutant]

> I prepared a small test that demonstrates the problem:
>
> % cat test.c
> void *dlopen (const char *pathname, int mode)
>    { return (void *) 0; }
>
> __attribute__ ((__symver__ ("dlopen@GLIBC_2.1")))
> void *__collector_dlopen_2_1 (const char *pathname, int mode)
>    { return (void *) 0; }
>
> __attribute__ ((__symver__ ("dlopen@GLIBC_2.0")))
> void *__collector_dlopen_2_0 (const char *pathname, int mode)
>    { return (void *) 0; }
>
> int main()
>    { return 0; }

The unbound copy of dlopen is the problem here. If you want a default
version, you should use a symver attribute with an "@@" on that copy.

> % cat map.txt
> GLIBC_2.0 {
>      global:
>         dlopen;
> };
>
> GLIBC_2.1 {
>      global:
>          dlopen;
> };

Normally, I'd expect the GLIBC_2.1 { ... } block to include all of
GLIBC_2.0, by naming the previous version after the closing brace.
This is irrelevant to this problem, but you might want to think about
that.

> There are no problems with -fuse-ld=bfd:
> % /opt/rh/gcc-toolset-10/root/bin/gcc -m32 test.c -Wl,--version-script
> -Wl,map.txt  -fuse-ld=bfd

You should also use -Wl,-E here. Otherwise, the symbols will not be
exported to the dynamic symbol table.

> The output of `nm` shows exactly what I expected:
> % nm a.out | grep dlopen
> 08049191 T __collector_dlopen_2_0
> 08049187 T __collector_dlopen_2_1
> 0804917d t dlopen
> 08049191 t dlopen@GLIBC_2.0
> 08049187 t dlopen@GLIBC_2.1

Here, you're just dumping the static symbol table. Use "nm -D" to dump
the dynamic symbol table, which is what you're really interested in.

> But with -fuse-ld=gold:
> % /opt/rh/gcc-toolset-10/root/bin/gcc -m32 test.c -Wl,--version-script
> -Wl,map.txt  -fuse-ld=gold
> /bin/ld.gold: warning: /tmp/cc6YCOol.o: unknown program property type
> 0xc0010001 in .note.gnu.property section
> /bin/ld.gold: warning: using 'GLIBC_2.0' as version for 'dlopen' which
> is also named in version 'GLIBC_2.1' in script
> /bin/ld.gold: error: /tmp/cc6YCOol.o: multiple definition of 'dlopen'
> /bin/ld.gold: /tmp/cc6YCOol.o: previous definition here
> collect2: error: ld returned 1 exit status

If you leave out the unbound version of dlopen, or symver it to a
third version node, this should work.

> My questions:
>
> Is my test correct ?

Sorry, I really don't know. The ld manual doesn't really cover this
case, nor do any of the ld test cases that I could find. BFD ld and
gold differ here, and I don't know whether or not to consider that a
bug.

> if not:
>    we need to interpose the dlopen functions from libdl.so.
>    How can I do it correctly ?

If you bind every version of dlopen to a different version node, it
should work in both linkers.

> If yes:
> Is this a known compiler bug in gold ? If not, do I need to create one ?
>    Is there a simple workaround ?

I hope binding the base version of dlopen to a separate version node
works for you. Whether to call that a workaround or a fix to your
testcase, I'm not sure.

-cary