octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #55447] mkoctfile: wrong LFLAGS warning, reset


From: Mike Miller
Subject: [Octave-bug-tracker] [bug #55447] mkoctfile: wrong LFLAGS warning, resets LDFLAGS
Date: Wed, 23 Jan 2019 17:34:09 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Follow-up Comment #9, bug #55447 (project octave):

No, I believe the current order is correct.

First note that vars["LDFLAGS"] is already included in vars["ALL_LDFLAGS"] for
the stand-alone link command. So appending it after vars["DL_LDFLAGS"] as I
did here just makes sure that the two commands are applying the user LDFLAGS
properly.

The stackoverflow question you point to is confusing LDFLAGS with LIBS or
LDLIBS. I think a large part of the confusion is users who group -L options
and -Wl options together with -l options. The first two are proper linker
options, the -l "options" are actual operands. LDFLAGS should not contain -l
arguments. But -l operands _do_ need to come after the 'objfiles' argument.

It's possible there will be some transition pain if users are stuffing "-lfoo"
operands into the LFLAGS variable. They should *not* start putting "-lfoo"
operands into LDFLAGS. They should either be passed on the mkoctfile command
line, or maybe we need to introduce an entirely new variable, such as "LIBS",
for this purpose.

If you look at the GNU make built-in rules or the automake link commands you
will see that LDFLAGS properly comes before any file arguments, just like
CPPFLAGS and CXXFLAGS.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?55447>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]