Linker parameters order requeriment: has it changed lately?

[vanfanel]

Hi there

I am very puzzled. I have just upgraded my system from Stable (Buster) to Testing (Bullseye).
Everything was fine, but I have noticed that I could, for example, do this on Buster and it would build with no problems:

Code: Select all

gcc -L/usr/lib -lSDL2 -I/usr/include/SDL2 example.c

But I have to do this on Bullseye or it will not build:

Code: Select all

gcc example.c -L/usr/lib -lSDL2 -I/usr/include/SDL2

So, what has changed? Where can I read about it? I have searched GCC docs with no answer about parameter order becoming strict lately.

Thanks!

[cuckooflew]

I don't know if the problem you have is listed here, but this is where testing users keep up to date on changes, https://lists.debian.org/debian-testing-changes/
===
When one changes from Debian Stable, (Buster) to the testing version, Debian testing (will be Bullseye),
it is, or should be expected, some things might not work as expected, etc. you know, since it is testing, ...
Maybe it is intentional, or maybe it is a bug, and you should submit a bug report.
If you do not want to help with the testing, and this is a problem,

Everything was fine, but I have noticed that I could, for example, do this on Buster and it would build with no problems

There you go, the solution is to stick with Debian stable (Buster), since every thing is /was fine.
When Debian Bullseye is finally released, and no longer in the testing, experimental stages, most likely everything will be fine on that as well. Usually the changes are also then announced, with the new release.

[neuraleskimo]

I don't know if there has been an official change. However, the canonical way to call gcc is with the source file at the end of the command.

Code: Select all

gcc --help
Usage: gcc [options] file...

Every makefile I have seen or written has followed that convention. Of course, that doesn't me make entirely correct.

Pure speculation on my part... Some changes to the command line parsing may have accidentally "fixed" any looseness in the parsing of arguments.

[EDIT: fixed a few typos.]

[reinob]

I don't know if there has been an official change. However, the canonical way to call gcc is with the source file at the end of the command.

Code: Select all

gcc --help
Usage: gcc [options] file...

Every makefile I have seen or written has followed that convention. Of course, that doesn't me make entirely correct.

Pure speculation on my part... Some changes to the command line parsing may have accidentally "fixed" any looseness in the parsing of arguments.

[EDIT: fixed a few typos.]

If you're compiling .c to object (.o) then yes, you use gcc like that.

However the linker (ld) needs the libraries *after* the objects, as otherwise it doesn't know what it needs from a library and discards everything, and then gets to the object and cannot resolve symbols. (Hint: objects and libraries are processed left to right).

Using gcc directly from .c to executable (like the OP did) requires an order that will suite the linker, hence:

Code: Select all

$ gcc program.c -library


(AFAIK -I and -L should be just before they are needed, preferably at the very beginning of the command line).

[neuraleskimo]

Oops! I misfired on that. Sorry! I will quietly go back to using CMake now.