[Bug driver/99896] New: g++ drops -lc

[Bug driver/99896] New: g++ drops -lc

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99896

            Bug ID: 99896
           Summary: g++ drops -lc
           Product: gcc
           Version: 10.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ Spinoff from gdb PR https://sourceware.org/bugzilla/show_bug.cgi?id=27681 . ]

Consider the following test-case, consisting of:
...
$ cat main.c 
#include <assert.h>
#include <stddef.h>

#ifndef _GNU_SOURCE
#define _GNU_SOURCE
#endif
#include <regex.h>

extern void foo (void);

int
main (void)
{
  regex_t re;

  int res = regcomp (&re, "bla", 0);
  assert (res == 0);

  int res2 = regexec (&re, "bla", 0, NULL, 0);
  assert (res2 == 0);

  regoff_t res3 = re_search (&re, "bla", 3, 0, 3, NULL);
  assert (res3 == 0);

  foo ();

  return 0;
} 
...
and:
...
$ cat foo.c 
#include <assert.h>
#include <stddef.h>

#include <pcre2posix.h>

extern void foo (void);

void
foo (void)
{
  regex_t re;

  int res = pcre2_regcomp (&re, "bla", 0);
  assert (res == 0);

  int res2 = pcre2_regexec (&re, "bla", 0, NULL, 0);
  assert (res2 == 0);
}
...

We can compile with gcc and run like this:
...
$ gcc main.c -lc foo.c -lpcre2-posix
$ ./a.out 
$
...

likewise, with clang:
...
$ clang main.c -lc foo.c -lpcre2-posix
$ ./a.out 
$ 
...

likewise, with clang++:
...
$ clang++ -x c++ main.c -lc foo.c -lpcre2-posix
$ ./a.out 
$
...

but with g++:
...
$ g++ -x c++ main.c -lc foo.c -lpcre2-posix
$ ./a.out 
Segmentation fault (core dumped)
$
...

Using -v, we can see what goes wrong.  With gcc, we have:
...
collect2 ... main.o -lc foo.o -lpcre2-posix ...
...

With g++, we have instead:
...
collect2 ... main.o foo.o -lpcre2-posix ...
...

Workaround: use -Wl:
...
$ g++ -x c++ main.c -Wl,-lc foo.c -lpcre2-posix
$ ./a.out 
$
...

[Bug driver/99896] g++ drops -lc

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99896

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> With g++, we have instead:
> ...
> collect2 ... main.o foo.o -lpcre2-posix ...
> ...

It isn't dropped, it's moved to the end:

main.o foo.o -lpcre2-posix -lstdc++ -lm -lc -lgcc_s -lgcc -lc -lgcc_s -lgcc

If you need it before foo.o then -Wl,-lc seems like the right workaround for
me.

Why is it needed there anyway though?

[Bug driver/99896] g++ drops -lc

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99896

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Tom de Vries from comment #0)
> > With g++, we have instead:
> > ...
> > collect2 ... main.o foo.o -lpcre2-posix ...
> > ...
> 
> It isn't dropped, it's moved to the end:
> 
> main.o foo.o -lpcre2-posix -lstdc++ -lm -lc -lgcc_s -lgcc -lc -lgcc_s -lgcc
> 

I don't understand. AFAICT, it's dropped.  It's not moved to the end, because
-lc is already at the end without specifying -lc. 

> If you need it before foo.o then -Wl,-lc seems like the right workaround for
> me.
> 

Um, for my understanding, does that mean you agree this is a bug in g++?

> Why is it needed there anyway though?

main.o is intended to use regcomp from glibc.  Foo.o is intended to use
pcre2_regcomp from pcre2-posix (which is also accessible using plain regcomp). 
When -lc is droppend, regcomp from pcre2-posix is used by main instead, which
is incompatible with using re_search from glibc.

[Bug driver/99896] g++ drops -lc

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99896

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
regcomp and re_search are always incompatible.

[Bug driver/99896] g++ drops -lc

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99896

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #2)
> I don't understand. AFAICT, it's dropped.  It's not moved to the end,
> because -lc is already at the end without specifying -lc. 

OK, it's dropped because it's always present at the end.

This is similar to adding -I/usr/include which gets ignored, because it's
already going to be searched anyway as a system header directory. Quoting the
manual:

"If a standard system include directory, or a directory specified with
-isystem, is also specified with -I, the -I option is ignored."


> Um, for my understanding, does that mean you agree this is a bug in g++?

No.

> > Why is it needed there anyway though?
> 
> main.o is intended to use regcomp from glibc.  Foo.o is intended to use
> pcre2_regcomp from pcre2-posix (which is also accessible using plain
> regcomp).  When -lc is droppend, regcomp from pcre2-posix is used by main
> instead, which is incompatible with using re_search from glibc.

Ohhh, this issue. It's clearly a bug in pcre2. Providing symbols with the same
names as the ones in libc, but with different ABI, is madness.

[Bug driver/99896] g++ drops -lc

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99896

--- Comment #5 from Andreas Schwab <schwab@linux-m68k.org> ---
The bug is in gdb because re_search cannot be paired with regcomp.

[Bug driver/99896] g++ drops -lc

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99896

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matz at suse dot de

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Tom de Vries from comment #2)
> > I don't understand. AFAICT, it's dropped.  It's not moved to the end,
> > because -lc is already at the end without specifying -lc. 
> 
> OK, it's dropped because it's always present at the end.
> 
> This is similar to adding -I/usr/include which gets ignored, because it's
> already going to be searched anyway as a system header directory. Quoting
> the manual:
> 
> "If a standard system include directory, or a directory specified with
> -isystem, is also specified with -I, the -I option is ignored."
> 
>  
> > Um, for my understanding, does that mean you agree this is a bug in g++?
> 
> No.
> 

OK, so here ( https://gcc.gnu.org/onlinedocs/gcc/Invoking-GCC.html#Invoking-GCC
) I read:
...
Also, the placement of the -l option is significant. 
...

So, if the documentation of gcc says that placement of the -l option is
significant, then why does g++ decide to mess with that?  ISTM g++ violates
documented behaviour.

[Bug driver/99896] g++ drops -lc

[matz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99896

Michael Matz <matz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matz at gcc dot gnu.org

--- Comment #7 from Michael Matz <matz at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Tom de Vries from comment #0)
> > With g++, we have instead:
> > ...
> > collect2 ... main.o foo.o -lpcre2-posix ...
> > ...
> 
> It isn't dropped, it's moved to the end:
> 
> main.o foo.o -lpcre2-posix -lstdc++ -lm -lc -lgcc_s -lgcc -lc -lgcc_s -lgcc
> 
> If you need it before foo.o then -Wl,-lc seems like the right workaround for
> me.

Workaround is the correct term here.  The correct thing would be for g++ to not
reorder -l arguments.  The similarity to -I is superficial: duplicated -l
arguments have meaning (with static archives for instance) and their position
in relation to object and source files matters.  g++ can validly tack on
additional -l arguments to the end, and arguably also replace a lone -lc
argument that was originally at the end of the command line or implicit (e.g.
to inject its unwinder), but it shouldn't otherwise reorder such arguments.

I will of course agree that the issue that the added -lc "solves" is actually
a bug in the testcase (and gdb).  But that should be immaterial here.  At the
very least gcc and g++ should behave the same in this respect.