Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #239613 > unrolled thread

gcc-10: options order important?

Back to article view | Back to linux.debian.user

Contents

  gcc-10: options order important? "Piotr A. Dybczyński" <piotr@dybczynski.pl> - 2021-09-03 12:30 +0200
    Re: gcc-10: options order important? Greg Wooledge <greg@wooledge.org> - 2021-09-03 13:40 +0200
    Re: gcc-10: options order important? Tixy <tixy@yxit.co.uk> - 2021-09-03 15:20 +0200
      Re: gcc-10: options order important? Greg Wooledge <greg@wooledge.org> - 2021-09-03 19:00 +0200
        Re: gcc-10: options order important? <tomas@tuxteam.de> - 2021-09-03 20:50 +0200
    Re: gcc-10: options order important? Tixy <tixy@yxit.co.uk> - 2021-09-03 15:20 +0200
    Re: gcc-10: options order important? Sven Joachim <svenjoac@gmx.de> - 2021-09-03 21:00 +0200

#239613 — gcc-10: options order important?

Hi,

in contrary to previous versions, now in Debian 11 with gcc-10:

gcc aa.c -lm -o aa           works, but

gcc -lm aa.c -o aa           does not work, saying: 

/usr/bin/ld: /tmp/ccWyhudO.o: in function `main':
aa.c:(.text+0x1f): undefined reference to `sqrt'
collect2: error: ld returned 1 exit status

My aa.c content:

-------------------------------------------
#include<stdio.h>
#include<math.h>

int main(void)
{
  double x=4;

  printf("sqrt(4)=%f\n",sqrt(x));

  return 0;
}
-------------------------------------------

It seems that an option -lm cannot be placed in an arbitrary place which I used to
do. Is this intentional ?

Regards,

Piotr A. Dybczyński
-- 
/**************************************************************************
                          dr Piotr A. Dybczyński 
 homepage: https://www.dybczynski.pl/Piotr     e-mail: piotr@dybczynski.pl
********************************************************************PAD***/

[toc] | [next] | [standalone]

#239614

On Fri, Sep 03, 2021 at 12:24:39PM +0200, Piotr A. Dybczyński wrote:
> Hi,
> 
> in contrary to previous versions, now in Debian 11 with gcc-10:
> 
> gcc aa.c -lm -o aa           works, but
> 
> gcc -lm aa.c -o aa           does not work, saying: 
> 
> /usr/bin/ld: /tmp/ccWyhudO.o: in function `main':
> aa.c:(.text+0x1f): undefined reference to `sqrt'
> collect2: error: ld returned 1 exit status

If this *ever* worked in the past, it was dumb luck.  Libraries need
to be given after the objects that use them.  That's how the linker
operates.

You can think of it this way: the linker scans through the list of object
files and libraries in a single pass, left to right.  In your non-working
command, the first thing it encounters is -lm (math library).  So it
checks for any unresolved symbols that it currently has, and tries to
match them against the math library.  There aren't any unresolved symbols
at this point (because no object files have been linked in yet), so it
doesn't pull anything out of the math library.

Next it encounters aa.o (implicitly compiled from aa.c), and it links in
that object file, which may have some unresolved symbols.  If there are
any, the linker expects that it'll be given a library afterward, to look
them up.

But... there is no library given after that.  It doesn't go *back* to
look at the math library a second time.

[toc] | [prev] | [next] | [standalone]

#239623

On Fri, 2021-09-03 at 14:10 +0100, Tixy wrote:
> On Fri, 2021-09-03 at 12:24 +0200, Piotr A. Dybczyński wrote:
> > Hi,
> > 
> > in contrary to previous versions, now in Debian 11 with gcc-10:
> > 
> > gcc aa.c -lm -o aa           works, but
> > 
> > gcc -lm aa.c -o aa           does not work, saying: 
> 
> [...]
> 
> > It seems that an option -lm cannot be placed in an arbitrary place which I used to
> > do. Is this intentional ?
> 
> I found this too, I just modified my Makefiles to have libraries after
> input files.
> 
> A man page a found online [1] says linking happens as Greg described, 
> and this is true looking at a 6 year old copy of that page on
> archive.org. So seems strange that for many years my Makefiles have
> worked with Libraries specified before inputs that use them.

Correction... 'for many years my Makefiles have worked with Libraries
specified _after_ inputs that use them'

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#239637

On Fri, Sep 03, 2021 at 02:12:46PM +0100, Tixy wrote:
> > A man page a found online [1] says linking happens as Greg described, 
> > and this is true looking at a 6 year old copy of that page on
> > archive.org. So seems strange that for many years my Makefiles have
> > worked with Libraries specified before inputs that use them.
> 
> Correction... 'for many years my Makefiles have worked with Libraries
> specified _after_ inputs that use them'

You had it right the first time.  It's strange that it worked (in the
past) with the library argument in front.  It's supposed to be behind.

The linker's argument processing must have been changed a few times.
GNU utilities in general have a tendency to be overly lenient with
command-line options.  Commands that *should* fail according to POSIX
sometimes work in the GNU variants.

For example:

unicorn:~$ ls .bashrc -l
-rwxr-xr-x 1 greg greg 2741 Sep  1 22:32 .bashrc*

That should *not* have worked, but GNU permits the option (-l) to be
handled even when it's in the wrong place.  (In standard POSIX ls,
that command should have tried to list a file named "-l", because
the non-option ".bashrc" terminates option processing.  All remaining
arguments are to be treated as files or directories.)

All I can speculate is that GNU ld (the linker that gcc uses) must have
had some tweaks done to it over the years, and now has settled back into
its original behavior.  An expert in GNU binutils (or even a changelog)
might have more details.

The way a gcc (or cc) command is supposed to be written is:

gcc [options] source/object files [-libraries]

The up-front [options] can include things like "-o foo" to specify an
output file other than a.out to the linker.  So, for example, the OP's
command should have been something like:

gcc -o foo foo.c -lm

That's the standard format, and is what you should be using in Makefiles
and similar files which call gcc.

[toc] | [prev] | [next] | [standalone]

#239643

[Multipart message — attachments visible in raw view] — view raw

On Fri, Sep 03, 2021 at 12:59:27PM -0400, Greg Wooledge wrote:
> On Fri, Sep 03, 2021 at 02:12:46PM +0100, Tixy wrote:
> > > A man page a found online [1] says linking happens as Greg described, 
> > > and this is true looking at a 6 year old copy of that page on
> > > archive.org. So seems strange that for many years my Makefiles have
> > > worked with Libraries specified before inputs that use them.
> > 
> > Correction... 'for many years my Makefiles have worked with Libraries
> > specified _after_ inputs that use them'
> 
> You had it right the first time.  It's strange that it worked (in the
> past) with the library argument in front.  It's supposed to be behind.
> 
> The linker's argument processing must have been changed a few times.
> GNU utilities in general have a tendency to be overly lenient with
> command-line options.  Commands that *should* fail according to POSIX
> sometimes work in the GNU variants.

[...]

It /might/ be related to weak linking and the default for
the --as-needed option in the linker. Caveat: I haven't found
the time to research this more thoroughly.

But OP could try to pass --no-as-needed and see what happens :)

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#239624

On Fri, 2021-09-03 at 12:24 +0200, Piotr A. Dybczyński wrote:
> Hi,
> 
> in contrary to previous versions, now in Debian 11 with gcc-10:
> 
> gcc aa.c -lm -o aa           works, but
> 
> gcc -lm aa.c -o aa           does not work, saying: 

[...]

> It seems that an option -lm cannot be placed in an arbitrary place which I used to
> do. Is this intentional ?

I found this too, I just modified my Makefiles to have libraries after
input files.

A man page a found online [1] says linking happens as Greg described, 
and this is true looking at a 6 year old copy of that page on
archive.org. So seems strange that for many years my Makefiles have
worked with Libraries specified before inputs that use them.

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#239645

On 2021-09-03 12:24 +0200, Piotr A. Dybczyński wrote:

> Hi,
>
> in contrary to previous versions, now in Debian 11 with gcc-10:
>
> gcc aa.c -lm -o aa           works, but
>
> gcc -lm aa.c -o aa           does not work, saying: 
>
> /usr/bin/ld: /tmp/ccWyhudO.o: in function `main':
> aa.c:(.text+0x1f): undefined reference to `sqrt'
> collect2: error: ld returned 1 exit status
>
> It seems that an option -lm cannot be placed in an arbitrary place which I used to
> do. Is this intentional ?

Yes, gcc now invokes ld with the --as-needed option.  This reduces
unnecessary linking and thereby Debian package dependencies, but it also
has the effect you are seeing, as mentioned in the binutils
documentation:

,----
| Object files or libraries appearing on the command line _after_ the
| library in question do not affect whether the library is seen as needed.
| This is similar to the rules for extraction of object files from
| archives.  '--no-as-needed' restores the default behaviour.
`----

Cheers,
       Sven

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web