Re: gcc-10: options order important?
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
Re: gcc-10: options order important?
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 signature.asc Description: Digital signature
Re: gcc-10: options order important?
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.
Re: gcc-10: options order important?
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
Re: gcc-10: options order important?
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
Re: gcc-10: options order important?
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.
