bugGNU Octave - Bugs: bug #48678, mkoctfile returns linker flags on...

 
 

bug #48678: mkoctfile returns linker flags on LFLAGS instead of LDFLAGS

Submitted by:  Carnë Draug <carandraug>
Submitted on:  Tue 02 Aug 2016 01:15:32 AM UTC  
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  3 - Low Item Group:  None
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Sun 14 Aug 2016 03:57:17 PM UTC, comment #10:

carandraug said:

> [...] therefore "-p" would be the flags that mkoctfile uses. [...] in my view that includes the flags required by Octave plus whatever the user has set in the environment if any.


I thought about this again last night and I'm not so sure if that's the most obvious behaviour after all.

Mike Miller said:

> Agree with jwe, I think it's important that mkoctfile treats CFLAGS, CPPFLAGS, CXXFLAGS, LDFLAGS, etc as user variables that can be overridden from the environment, and default to empty (in the case of LDFLAGS) or to a trivial default (in the case of CXXFLAGS="-g -O2").
>
> But do we want to append the built-in defaults to the user values and allow the full set of flags to be exported? Or would that be too confusing?


Yes, mkoctfile should account for XFLAGS set in the environment but it doesn't have to echo them back when using "mkoctfile -p".

If mkoctfile is called to make an oct file, then it should use env variables. If it is called with "-p", then the user will be handling those flags and it is up to him to append any environment variables that it sees fit, and it will be up to him to ignore the environment variables as well. pkg-config also does this, it returns only the flags required and ignores environment variables.

But then the purpose of "mkoctfile -p" overlaps with the purpose of "octave-config" and the newly reported bug about supporting pkg-config. So why do we even need "mkoctfile -p"?

Carnë Draug <carandraug>
Project Member
Sun 14 Aug 2016 02:01:06 PM UTC, comment #9:

I don't see the reason to delay. I find it awfully confusing that mkoctfile -p doesn't return the actual set of values that it uses internally to compile objects.

Rik <rik5>
Project Administrator
Sat 13 Aug 2016 11:41:46 PM UTC, comment #8:

jwe said on comment #7:

> That we provide octave-config and not a pkg-config file is really just historical (pkg-config wasn't around yet?). Switching to pkg-config and deprecating octave-config is probably worthy of a separate bug report/feature request.


New bug report opened as bug #48775

Should then fixing this be delayed until we provide a pkg-config file then?

Carnë Draug <carandraug>
Project Member
Sat 13 Aug 2016 11:20:03 PM UTC, comment #7:

That we provide octave-config and not a pkg-config file is really just historical (pkg-config wasn't around yet?). Switching to pkg-config and deprecating octave-config is probably worthy of a separate bug report/feature request.

John W. Eaton <jwe>
Project Administrator
Sat 13 Aug 2016 11:09:05 PM UTC, comment #6:

That explains the large set of flags. I never quite understood why we had so many and why they looked kind of redundant.

I thought the purpose of mkoctfile was to build oct files and that therefore "-p" would be the flags that mkoctfile uses. Because mkoctfile should not ignore user environment variables, in my view that includes the flags required by Octave plus whatever the user has set in the environment if any.

If a user would want to get only the flags that Octave requires (instead of the flags that mkoctfile will use), then it should use octave-config (which I now realize doesn't really have any flags and is not an Octave specific version of pkg-config).

Carnë Draug <carandraug>
Project Member
Sat 13 Aug 2016 10:44:32 PM UTC, comment #5:

Agree with jwe, I think it's important that mkoctfile treats CFLAGS, CPPFLAGS, CXXFLAGS, LDFLAGS, etc as user variables that can be overridden from the environment, and default to empty (in the case of LDFLAGS) or to a trivial default (in the case of CXXFLAGS="-g -O2").

But do we want to append the built-in defaults to the user values and allow the full set of flags to be exported? Or would that be too confusing?

For example could we combine the user's CPPFLAGS with what is currently called INCFLAGS, and export that from "mkoctfile -p CPPFLAGS"? Same with user's CXXFLAGS and XTRA_CXXFLAGS for "mkoctfile -p CXXFLAGS"?

Another enhancement might be to work on the naming convention of the built-in compiler/linker options. It usually takes me a few tries of guessing to figure out which of LFLAGS, OCTAVE_LIBS, DL_LDFLAGS, I need to export to build something.
It might be a nice enhancement to work on the naming scheme for exporting the default flags from mkoctfile.

Mike Miller <mtmiller>
Project Administrator
Sat 13 Aug 2016 10:27:10 PM UTC, comment #4:

The LDFLAGS variable is normally empty and allows the user to add options by setting LDFLAGS in the environment.

It looks like the LFLAGS variable is just there to ensure that -L$(octlibdir) is included in the linker options when it is not a directory that is normally searched by the linker. I suppose it is similar to AM_LDFLAGS in automake. LFLAGS may not be the best name, but this job needs to be done in some way. It's probably best to keep it separate from LDFLAGS so that if someone sets LDFLAGS in the environment, they don't have to also include -L/usr/local/octave/lib/.../whatever. Users should be able to set LDFLAGS independently and still expect things to work.

John W. Eaton <jwe>
Project Administrator
Sat 13 Aug 2016 02:52:15 PM UTC, comment #3:

Adding jwe to the CC list. I think this is still some sort of simple misunderstanding.

Rik <rik5>
Project Administrator
Sat 13 Aug 2016 02:46:15 PM UTC, comment #2:

Looking into mkoctfile.in.cc, I see that LFLAGS is supposedly being set as something from configure.ac

While LFLAGS is being set "manually"

I don't quite get it, there's no tests units for this, and I'm not comfortable tweaking there. Could anyone more familiar have its hand at it?

Carnë Draug <carandraug>
Project Member
Fri 12 Aug 2016 12:24:50 AM UTC, comment #1:

This is us just being stupid. If you try 'mkoctfile -h' the documentation clearly says that LDFLAGS should be a configuration variable.

I would say go ahead and make the change. We can keep LFLAGS for another two releases.

Rik <rik5>
Project Administrator
Tue 02 Aug 2016 01:15:32 AM UTC, original submission:

From the Make manual https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html

However, mkoctfile includes the LDFLAGS into LFLAGS instead

This is bug is also present in Octave 4.0.1 (and possibly in previous versions)

and so there's backwards compatibility implications about fixing this. But since mkoctifle does not handle lex, it would be possible to keep using LDFLAGS incorrectly for a few versions, before removing LFLAGS completely.

Carnë Draug <carandraug>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by carandraug (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-05-17 mtmiller CategoryNone => Configuration and Build System
        Priority5 - Normal => 3 - Low
    2016-08-13 rik5 Carbon-Copy- => Added jwe
    2016-08-12 rik5 StatusNone => Confirmed

    Back to the top


    Powered by Savane 3.3