bugGNU Octave - Bugs: bug #59173, "mkoctfile -p" returns...

 
 

bug #59173: "mkoctfile -p" returns wrong values for certain flags on cross-built systems (Windows)

Submitter:  Markus Mützel <mmuetzel>
Submitted:  Wed 23 Sep 2020 08:35:33 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 6.0.90 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 25 Oct 2020 09:23:33 AM UTC, comment #48: 

@jwe: Thank you for cleaning this up.

This seems to be working correctly for me now.
Closing as fixed again.

Markus Mützel <mmuetzel>
Group administrator
Tue 20 Oct 2020 05:57:57 AM UTC, comment #47: 

Making this change was a bit more complicated than I thought it would be because argument parsing and actions on the VARS map were mixed together.  I checked in a couple of patches to separate parsing from actions:

http://hg.savannah.gnu.org/hgweb/octave/rev/f29e4791a792
http://hg.savannah.gnu.org/hgweb/octave/rev/091aeae73b60

Then another one to skip adding DL_LDFLAGS to the default value for LDFLAGS when linking a stand alone programs:

http://hg.savannah.gnu.org/hgweb/octave/rev/d24e34e179ab

And one more to prefix all warning messages with "mkoctfile: ":

http://hg.savannah.gnu.org/hgweb/octave/rev/b02d9109fb6e

Marking as ready for test.

John W. Eaton <jwe>
Group administrator
Mon 19 Oct 2020 07:40:35 PM UTC, comment #46: 

@jwe, re: comment #45: That sounds reasonable to me.

Markus Mützel <mmuetzel>
Group administrator
Mon 19 Oct 2020 07:24:06 PM UTC, comment #45: 

Re-opening because after this change

http://hg.savannah.gnu.org/hgweb/octave/rev/6d50f931e810

programs compiled with --link-stand-alone may be linked with options that are intended for building shared libraries, not executable programs.  On my system the options "-shared -Wl,-Bsymbolic" are used in final link flags.  Those are correct for building shared libraries but not programs.

I guess the correct fix is to skip setting DEFAULT_LDFLAGS to DL_LDFLAGS if link_stand_alone is true?

John W. Eaton <jwe>
Group administrator
Sat 10 Oct 2020 12:27:08 PM UTC, comment #44: 

I finished cross-compiling a version with that fix. Only for FLIBS, the simple search and replace approach doesn't work. The other flags look ok to me.
We already knew that it won't work for FLIBS.

I'm tentatively closing this report as fixed. Please, re-open if you think we should keep it open for FLIBS.

Markus Mützel <mmuetzel>
Group administrator
Fri 09 Oct 2020 03:29:36 PM UTC, comment #43: 

Okay.  I can't test because I only do Linux builds so someone else will have to help out here.

Rik <rik5>
Group administrator
Fri 09 Oct 2020 03:10:59 PM UTC, comment #42: 

It isn't really needed for `subst-cross-config-vals.in.sh` because that will create the cross-compiler that executes on the build system. It is necessary for `subst-config-vals.in.sh`.
I made the change in both files to keep the them as similar as possible (like they currently are).

FWIW, gcc makes a difference between build, host and target platform. Thankfully, host and target is the same for us. (But it might be possible to build a `mkoctfile` executable on Linux that builds Linux executables on Windows.)

Markus Mützel <mmuetzel>
Group administrator
Fri 09 Oct 2020 02:58:28 PM UTC, comment #41: 

Does the substitution need to take place in both subst-config-vals.in.sh and subst-cross-config-vals.in.sh or is only the cross-compilation sufficient?

Rik <rik5>
Group administrator
Fri 09 Oct 2020 02:23:30 PM UTC, comment #40: 

I re-ordered the flags in the patch from comment #4 alphabetically and pushed it here:
https://hg.savannah.gnu.org/hgweb/octave/rev/d7169f012ee1

Marking as ready for test.

Markus Mützel <mmuetzel>
Group administrator
Thu 08 Oct 2020 08:00:06 PM UTC, comment #39: 

I think a brittle solution is still better than no solution at all right now.  I have no objections to using a search&replace script in the short term until we can think of something better.

Rik <rik5>
Group administrator
Thu 08 Oct 2020 05:59:13 PM UTC, comment #38: 

For the remaining issue, I think something like the patch in comment #4 is the best that we can do at the moment.

If we were able to use C++17, we could try to separate the -L flags and use `std::filesystem::path::lexically_relative` to get the path relative to the ${prefix}.

For now, matching ${prefix} in the flags literally is probably good enough for most cases imho.

Markus Mützel <mmuetzel>
Group administrator
Wed 07 Oct 2020 10:10:46 PM UTC, comment #37: 

I re-titled the bug report.  We still need a solution for the flags mentioned in comment #29.

Rik <rik5>
Group administrator
Wed 07 Oct 2020 10:09:29 PM UTC, comment #36: 

I suppose we could remove the empty deprecated properties table from NEWS for version 6, but it also doesn't bother me to leave it so that there is a parallel structure in the next section.

Rik <rik5>
Group administrator
Wed 07 Oct 2020 07:50:14 AM UTC, comment #35: 

I didn't realize how much I was relying on the notifications until now that they aren't working. Manually checking reports for updates is tedious. But enough of ranting...

I pushed your proposed update to the NEWS file and to the deprecation comment here:
https://hg.savannah.gnu.org/hgweb/octave/rev/ba6e10c316d3

I noticed that there is an empty table (no deprecated properties) in the NEWS file for Octave 6. Do we want to remove that before the release?

It is still an open question how we should tread the other flags listed in comment #29.
Should we open a new report for those? The `LDFLAGS` from the bug title should be working now for cross-builds...

Markus Mützel <mmuetzel>
Group administrator
Sat 03 Oct 2020 02:14:15 PM UTC, comment #34: 

I don't think it hurts to overcommunicate.  We can tell programmers again in the NEWS file that "LFLAGS" is deprecated and will be removed.  I'm fine with removing it in Octave 8 and adjusting both the NEWS and FIXME comments to reflect that.

Rik <rik5>
Group administrator
Thu 01 Oct 2020 05:39:15 PM UTC, comment #33: 

The note in NEWS.5 didn't give notice of when `LFLAG` would be removed. Do we need to announce the removal again? Afaict, such announcements haven't been repeated in the past.

Would it be enough to change the FIXME in mkoctfil.in.cc to mark the removal for Octave 8?

Markus Mützel <mmuetzel>
Group administrator
Wed 30 Sep 2020 08:10:26 PM UTC, comment #32: 

Yes, we do intend to get rid of LFLAGS when we can.

As suspected, it is going to require some careful thinking about which parts of mkoctfile and the configuration and build system as a whole need changing.

Rik <rik5>
Group administrator
Wed 30 Sep 2020 04:15:05 PM UTC, comment #31: 

Re comment #29:
Atm, these variables are hardcoded into mkoctfile (via build-aux/subst-config-vals.in.sh).
I don't know how the installer could fix these up unless we change completely how we manage these values.

Markus Mützel <mmuetzel>
Group administrator
Wed 30 Sep 2020 04:07:44 PM UTC, comment #30: 

I pushed the initial patches. But the connection to hg.savannah.gnu.org is very flaky for me atm.

I'll try making the changes for comment #28 later.

The note in NEWS.5 says the following:

- The environment variable used by `mkoctfile` for linker flags is now
  `LDFLAGS` rather than `LFLAGS`.  `LFLAGS` is deprecated, and a warning
  is emitted if is used, but it will continue to work.


Did we plan to never remove LFLAGS?

Markus Mützel <mmuetzel>
Group administrator
Wed 30 Sep 2020 02:40:23 PM UTC, comment #29: 

Actually, there is another issue previously identified.  These flags return the wrong result (for build system rather than host)


ALL_LDFLAGS
CPPFLAGS
LDFLAGS
OCT_LINK_OPTS
FFTW3F_LDFLAGS
FFTW3_LDFLAGS
FLIBS


Markus proposed a search and replace on the prefix as a possible fix.  Is there a way to do this that would be more reliable?

Maybe we need to have the install system on Windows fix up these variables.

Rik <rik5>
Group administrator
Wed 30 Sep 2020 02:33:23 PM UTC, comment #28: 

The re-ordering of linker flags to appear last definitely needs to happen.

I also think that we are so late in the 6.1 release process that we probably just need to put in a temporary fix so that octfiles can be built.

If that is what your three patches accomplish then I'm fine with them.

Other things that still need doing:

1) Update FIXME notes to reference correct version when LFLAGS will be removed.
2) Add a note about deprecation in NEWS file (can probably just pull the existing note from NEWS.5)




Rik <rik5>
Group administrator
Wed 30 Sep 2020 02:12:57 PM UTC, comment #27: 

Forgot to show the patch that I tried for the Makefile of the control packages.
Here it is.

With that change, control only builds successfully for Windows if I also apply "bug59173_3-mkoctfile_LDFLAGS_last_stable.patch".
Without the latter patch, compilation fails with lots of linker errors (mostly BLAS functions).

(file #49895)

Markus Mützel <mmuetzel>
Group administrator
Wed 30 Sep 2020 10:09:31 AM UTC, comment #26: 

It looks like LDFLAGS is passed too early in the flags that mkoctfile uses. That is what I would like to change on stable with "bug59173_3-mkoctfile_LDFLAGS_last_stable.patch".
When that is done, packages can start the transition from using LFLAGS to LDFLAGS and still be able to compile for Windows.

Packages currently have to use LFLAGS if they want to be able to compile for Windows. That means maintainers couldn't start making the change as advised in the current deprecation message.

If we fix that now, I think we should give the two versions transition time that we usually have for deprecation - starting from now. So if we start to support using LDFLAGS now on stable, we could remove LFLAGS in Octave 8 (not Octave 9 like I wrote before).

I think that the other two patches are an improvement compared to the current behavior. But I am not 100% convinced that they can be applied without any side effects. That is why I would like to apply them on default (given that Octave 6 is hopefully close to release).
If we are sure that they won't cause any harm, we could also apply the on stable. But that wouldn't change the previous points.

Both patches might cause different issues. That is why I would prefer to apply them separately.

Markus Mützel <mmuetzel>
Group administrator
Wed 30 Sep 2020 09:49:29 AM UTC, comment #25: 

How would the 3-patch system resolve the compilation problem with the control package?  From jwe's comment I inferred that using LFLAGS was not the right thing to do in that Makefile, and that seemed to be the inspiration for embarking on a different course.

Rik <rik5>
Group administrator
Wed 30 Sep 2020 06:50:54 AM UTC, comment #24: 

I would like to revert https://hg.savannah.gnu.org/hgweb/octave/rev/aab67699cbf6 (and mark LFLAG for removal in Octave 9).
After that, I'd like to apply Rik's rebased patch (bug59173_1-mkoctfile_LDFLAGS_default.patch) and an additional one that adds DL_LDFLAGS on the default branch (bug59173_2-mkoctfile_DL_LDFLAGS_default.patch).
Additionally, I'd like to change the order in which flags are passed on stable (bug59173_3-mkoctfile_LDFLAGS_last_stable.patch) and merge with default.

Does that sound reasonable?

(file #49891, file #49892, file #49893)

Markus Mützel <mmuetzel>
Group administrator
Tue 29 Sep 2020 08:30:01 PM UTC, comment #23: 

I couldn't get the control package to compile using LDFLAGS with that change alone. Instead, I had to change the order in which mkoctfile passes flags (see the attached patch).

So it looks like LDFLAGS cannot be used like implemented in Octave 5. In that case, we should fix that for Octave 6 and have LFLAGS deprecated for at least another two versions, imho.

(file #49890)

Markus Mützel <mmuetzel>
Group administrator
Tue 29 Sep 2020 06:31:16 PM UTC, comment #22: 

There is also this configure check which also references .oct and .mex files:
http://hg.savannah.gnu.org/hgweb/octave/file/6ec04c206ac4/m4/acinclude.m4#l2784

It's already possible to query `DL_LDFLAGS` from mkoctfile.
Maybe it would make sense to add it to DEFAULT_LDFLAGS and then follow Rik's patch in comment #13.

I'm currently cross-building stable with the attached change which is similar to Rik's patch. (Some packages don't build for default at the moment.)

(file #49889)

Markus Mützel <mmuetzel>
Group administrator
Tue 29 Sep 2020 03:03:58 PM UTC, comment #21: 

OK, the --export-all-symbols option is added here:

http://hg.savannah.gnu.org/hgweb/octave/file/6ec04c206ac4/configure.ac#l2463

It was added in this changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/db4453f40550

See also this mailing list discussion:

https://lists.gnu.org/archive/html/octave-maintainers/2013-07/msg00171.html

I don't think this flag is specific to Java.  It is added to the Octave build flags so that the symbols from our DLLs will all be exported, the same as they are by default on Unixy systems.  The other alternative is to create export lists and export only those symbols that we choose to make visible.

It's not clear to me whether this flag would be needed by packages, though we do need something that will export at least the symbols necessary for loading .oct file functions.

John W. Eaton <jwe>
Group administrator
Tue 29 Sep 2020 02:39:26 PM UTC, comment #20: 

At the moment, LDFLAGS is the following for Windows cross-builds (see comment #0):

>> mkoctfile -p LDFLAGS
-Wl,-rpath-link,/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/lib -Wl,--export-all-symbols


If we make it such that LDFLAGS is what LFLAGS previously was (see comment #11), it will be (comment #0):

>> mkoctfile -p LDFLAGS
-LC:\PROGRA~1\GNUOCT~1\OCTAVE~1.90\mingw64\lib\octave\6.0.90 -LC:\PROGRA~1\GNUOCT~1\OCTAVE~1.90\mingw64\lib


If packages got `-Wl,--export-all-symbols` from LDFLAGS (which I don't know if it is the case), that flag might get lost by that change.

Markus Mützel <mmuetzel>
Group administrator
Tue 29 Sep 2020 02:32:00 PM UTC, comment #19: 

What is the change that could remove --export-all-symbols?  What is adding that to LDFLAGS or LFLAGS?

John W. Eaton <jwe>
Group administrator
Tue 29 Sep 2020 02:03:32 PM UTC, comment #18: 

The change that might remove "-Wl,--export-all-symbols" hasn't been pushed yet.

It might make sense to open bug reports for each affected package. It would be best if this was fixed upstream.

Markus Mützel <mmuetzel>
Group administrator
Tue 29 Sep 2020 01:53:48 PM UTC, comment #17: 

Looking at the logs, --export-all-symbols appears in the verbose output of the mkoctfile commands.

But the control package Makefile has this:


LFLAGS := $(shell $(MKOCTFILE) -p LFLAGS) $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)

...

# slicot functions
__control_slicot_functions__.oct: __control_slicot_functions__.cc common.cc slicotlibrary.a
        LFLAGS="$(LFLAGS)" \
    $(MKOCTFILE) $(PKG_CXXFLAGS) __control_slicot_functions__.cc common.cc slicotlibrary.a


This is probably not the best way to link with these extra libraries, so maybe a better solution can be found, but in the meantime, we can add a patch in mxe-octave for the control package to use LDFLAGS instead of LFLAGS for this purpose.

John W. Eaton <jwe>
Group administrator
Tue 29 Sep 2020 01:41:53 PM UTC, comment #16: 

Since I can access the full build logs, I'm looking at the control package build problem.  If I can't figure out what the difference is quickly, I'll post some log files and ask for help.

John W. Eaton <jwe>
Group administrator
Tue 29 Sep 2020 01:03:49 PM UTC, comment #15: 

I can't tell from the link to the log file what the problem with the control package is.  But, this is why I wanted to make the LFLAGS change early in the 7.1 development cycle so we can catch these things.

If "-Wl,--export-all-symbols" is necessary on Windows, and isn't being provided in some other way, then it can be added to the DEFAULT_LDFLAGS in mkoctfile.in.cc under the protection of a #ifdef checking for Windows platform.

Rik <rik5>
Group administrator
Tue 29 Sep 2020 06:22:57 AM UTC, comment #14: 

There seems to be at least one package that might have problems with the missing LFLAGS. The `control` package is failing to cross-compile with a linker error:
http://buildbot.octave.org:8010/#/builders/14/builds/880/steps/8/logs/stdio

I'll try to have a closer look at the error when I come around to it.

Wrt the possibly missing linker flags, I'm more worried about "-Wl,--export-all-symbols". I believe to have read somewhere that this flag is necessary on Windows. But I don't remember where I read that or what is the reason it is needed.
I'll try your patch from comment #13 and see if that causes any issues.

Markus Mützel <mmuetzel>
Group administrator
Mon 28 Sep 2020 10:47:15 PM UTC, comment #13: 

Yes, it should be no worse than what exists today.  The option


-Wl,-rpath-link,/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib


sends the option "-rpath-link=directory" to the linker.  Given that the directory mentioned is never going to be valid (it was a temporary scratch directory used during the cross build) I can't see it mattering.

Of course, the real test is whether mkoctfile will correctly compile packages like sparsersb with such a configuration.

I'm attaching a changeset that implements the suggestion to switch between the environmental variable LDFLAGS (if defined) and a DEFAULT_LDFLAGS variable that is correctly set for the host.  It turns out that we were already using this coding pattern for INCFLAGS so I think it will work.

In any case, the patch is attached and if you could check it that would help.

(file #49881)

Rik <rik5>
Group administrator
Mon 28 Sep 2020 06:35:16 PM UTC, comment #12: 

Dang! The problem I had with the sparsersb package wasn't caused by the wrong LDFLAGS but by me not knowing the right way to do things. Sorry for that.

Still, the flags returned by mkoctfile look strange.
But maybe we can lower the priority until we find a real life problem.

The change that Rik proposes in comment #11 is much less intrusive and might be what is expected since LDFLAGS should be used as a replacement of the deprecated LFLAGS. And that change will make `mkoctfile -p LDFLAGS` return the same that `mkoctfile -p LFLAGS` returned previously.
Is it ok that additional flags (like "-Wl,--export-all-symbols" from comment #0) might be lost?

Markus Mützel <mmuetzel>
Group administrator
Mon 28 Sep 2020 06:01:31 PM UTC, comment #11: 

So at least for LDFLAGS, Octave probably needs some special case logic.  On Linux, gcc seems to automatically add or find the correct libraries.

I tried


g++ -c  -fPIC -I/usr/local/include/octave-5.2.0/octave/.. -I/usr/local/include/octave-5.2.0/octave -I/usr/local/include  -pthread -fopenmp -O2 -pipe    helloworld.cc -o /tmp/oct-7r1PK2.o
g++ -I/usr/local/include/octave-5.2.0/octave/.. -I/usr/local/include/octave-5.2.0/octave -I/usr/local/include  -pthread -fopenmp -O2 -pipe -shared -Wl,-Bsymbolic   -o helloworld.oct  /tmp/oct-7r1PK2.o    -L/usr/local/lib


Note how gcc adds "-L/usr/local/lib" for the link stage.

The motivating reason for getting rid of LFLAGS is that this variable is actually supposed to be used for passing flags to lex compilations, not C++ compilations.  And the the user should always be able to make the final determination.  If they want to override LDFLAGS they should be able to.  It is possible that something like this would work


vars["LDFLAGS"] = get_variable ("LDFLAGS", DEFAULT_LDFLAGS);


with the same logic to set DEFAULT_LDFLAGS as before.  In this case, the default would be taken not from Octave's build configuration, but from the variable inside mkoctfile.

Rik <rik5>
Group administrator
Mon 28 Sep 2020 04:47:22 PM UTC, comment #10: 

I was calling "mkoctfile" from the Octave prompt in comment #0.

What John D was pointing out in comment #7 is probably related to these lines of code:
https://hg.savannah.gnu.org/hgweb/octave/file/d28016d16e9a/src/mkoctfile.in.cc#l235

#if (defined (OCTAVE_USE_WINDOWS_API) || defined (CROSS)) || (defined __APPLE__ && defined __MACH__)

  // We'll be linking the files we compile with -loctinterp and -loctave,
  // so we need to know where to find them.
  DEFAULT_LDFLAGS += "-L" + quote_path (vars["OCTLIBDIR"]);
#endif


So no matter what `vars["LDFLAGS"]` is, there is a -L flag with the path to the Octave libraries when mkoctfile is called to compile .oct files.

If a package wants to know which flags to use for linking to the Octave libraries, "mkoctfile -p" returns some flags that are nonsense (or incomplete) on Windows (and probably for any cross-builds) at the moment.

For completeness, `LDFLAGS` isn't set in Octave on Windows:

>> getenv('LDFLAGS')
ans =
>>


The cross-build with this patch is almost finished. I'll report the results.

Markus Mützel <mmuetzel>
Group administrator
Mon 28 Sep 2020 04:19:40 PM UTC, comment #9: 

I removed LFLAGS from Octave in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/aab67699cbf6).  This removal was scheduled to take place before the 7.1 release, but it feels important to do this now so we uncover any problems in the build system well ahead of time.

Rik <rik5>
Group administrator
Mon 28 Sep 2020 03:58:21 PM UTC, comment #8: 

mkoctfile always checks the environment variable first and uses that in preference to anything set during the build configuration.  See src/mkoctfile.in.cc.  For this particular example,


  vars["LDFLAGS"] = get_variable ("LDFLAGS", %OCTAVE_CONF_LDFLAGS%);


On Linux, this just generally works and the override mechanism is only used when the user themselves have specified something.

I suspect on cross-builds anything from the build machine is likely to be incorrect.  Does Octave's initialization file for windows (.bat or .vbs) set up the environment variables so that mkoctfile works correctly?

If so, it may be that mkoctfile the executable should not be called directly from the command line but needs a wrapper to set the environment variables correctly.

I'm just guessing that the Makefile for sparsersb calls 'mkoctfile -p LDFLAGS' directly from the command line.  An replacement, just to see if this works, would be


octave --eval 'mkoctfile -p LDFLAGS'



Rik <rik5>
Group administrator
Mon 28 Sep 2020 12:35:43 PM UTC, comment #7: 

mkoctfile adds the 'dynamic' -L path from to the mkoctfile options so generally it works - it just has the build options also specified.

John Donoghue <lostbard>
Group Member
Mon 28 Sep 2020 06:34:41 AM UTC, comment #6: 

I regularly compile .oct files on Windows before doing similar changes in core files. That is by far faster than cross-compiling Octave completely and allows for a more efficient development cycle (at least with the trial-and-error approach I often find me using).
So in my experience, `mkoctfile` generally works on Windows.
But if necessary, I am passing flags manually.
I ran across the issue here when I tried to run `pkg install -forge sparsersb` for another bug. `sparsersb` uses `mkoctfile -p LDFLAGS` in its makefile.

Now that bug #59189 is fixed, I'll try again cross-compiling with the patch from here.

Markus Mützel <mmuetzel>
Group administrator
Mon 28 Sep 2020 02:50:16 AM UTC, comment #5: 

Does mkoctfile work at all on Windows (it should).  For reference, there are code samples in the examples/code directory.  Find that directory and then try


mkoctfile helloworld.cc


It should compile a .oct file that the running instance of Octave can use.

Rik <rik5>
Group administrator
Sun 27 Sep 2020 01:02:08 PM UTC, comment #4: 

Running the command from Rik's comment #3 with the release candidate:

$ octave-cli.exe --eval '__octave_config_info__ ()' | grep scratch
        ARPACK_CPPFLAGS = -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include/arpack
        ARPACK_LDFLAGS = -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib
        CPPFLAGS = -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include
        FFTW3F_CPPFLAGS = -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include
        FFTW3F_LDFLAGS = -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib
        FFTW3_CPPFLAGS = -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include
        FFTW3_LDFLAGS = -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib
        FLIBS =  -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/lib -L/scratch/build/release/mxe-octave-w64/usr/lib/gcc/x86_64-w64-mingw32/9.3.0 -L/scratch/build/release/mxe-octave-w64/usr/lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/lib/../lib -L/scratch/build/release/mxe-octave-w64/usr/lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/lib -lm -lgfortran -lmingw32 -lmoldname -lmingwex -lmsvcrt -lquadmath -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32
        FLTK_CPPFLAGS = -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include
        FLTK_LDFLAGS = -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib  -Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc
        FONTCONFIG_CPPFLAGS = -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include/freetype2 -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include/libpng16 -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include
        FT2_CPPFLAGS = -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include/freetype2 -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include/libpng16 -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include
        FT2_LIBS = -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib -lfreetype
        LDFLAGS = -Wl,-rpath-link,/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/lib -Wl,--export-all-symbols
        MAGICK_CPPFLAGS = -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include/GraphicsMagick -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include/libxml2 -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include
        MAGICK_LDFLAGS = -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib
        OCT_LINK_OPTS = -Wl,-rpath-link,/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/lib -Wl,--export-all-symbols
        PCRE_CPPFLAGS = -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include
        PCRE_LDFLAGS = -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib
        QHULL_CPPFLAGS = -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include
        QHULL_LDFLAGS = -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib
        QT_CPPFLAGS = -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/include/QtNetwork -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/include -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/include/QtPrintSupport -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/include -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/include/QtHelp -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/include -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/include/QtWidgets -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/include -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/include/QtGui -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/include -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/include/QtSql -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/include -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/include/QtXml -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/include -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/include/QtCore -I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/include
        QT_LDFLAGS = -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/lib
        config_opts =  'CPPFLAGS=-I/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include' 'LDFLAGS=-L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib' '--host=x86_64-w64-mingw32' '--build=x86_64-pc-linux-gnu' '--prefix=/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32' '--disable-silent-rules' '--enable-install-build-logs' 'FLTK_CONFIG=/scratch/build/release/mxe-octave-w64/usr/bin/x86_64-w64-mingw32-fltk-config' 'gl_cv_func_gettimeofday_clobber=no' 'gl_cv_func_tzset_clobber=no' '--with-blas=-lblas -lxerbla' '--enable-64' 'ax_blas_f77_func_ok=yes' 'ax_blas_integer_size=4' 'octave_cv_sizeof_fortran_integer=4' '--with-java-includedir=/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/include/java' '--disable-jit' 'MOC_QTVER=/scratch/build/release/mxe-octave-w64/usr/bin/x86_64-w64-mingw32-moc' 'UIC_QTVER=/scratch/build/release/mxe-octave-w64/usr/bin/x86_64-w64-mingw32-uic' 'RCC_QTVER=/scratch/build/release/mxe-octave-w64/usr/bin/x86_64-w64-mingw32-rcc' 'LRELEASE_QTVER=/scratch/build/release/mxe-octave-w64/usr/bin/x86_64-w64-mingw32-lrelease' 'octave_cv_lib_qscintilla=-lqscintilla2_qt5' 'LDFLAGS=-Wl,-rpath-link,/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/lib' '--with-x=no' '--enable-cross-tools' 'PKG_CONFIG=/scratch/build/release/mxe-octave-w64/usr/bin/pkg-config' 'PKG_CONFIG_PATH=/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/lib/pkgconfig:/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib/pkgconfig' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-w64-mingw32'


Is this supposed to show how Octave was configured? Or should these contain the flags that should be used on the target? I was assuming it was the former. So afaict, nothing needs to change here. (Unless we want to "anonymize" the distributed builds. But that should be a different report imho.)

I manually went through all `mkoctfile -p` variables listed by `mkoctfile --help`.
The following ones contain `-L` flags that are valid on the build system but not on the host system:

ALL_LDFLAGS
CPPFLAGS
LDFLAGS
OCT_LINK_OPTS
FFTW3F_LDFLAGS
FFTW3_LDFLAGS
FLIBS


All other variables look good to me with the release candidate.

The attached patch substitutes those parts of these flags that match `prefix` on the build system with the `prefix` valid on the host system.
Maybe we should do the same for some of the other flags, too? (Probably at least all the `*_LDFLAGS`.)

E.g.:

$ mkoctfile -p LDFLAGS
-Wl,-rpath-link,D:\SVN\Octave\test\OCTAVE~1\OCTAVE~1\mingw64\\/lib -LD:\SVN\Octave\test\OCTAVE~1\OCTAVE~1\mingw64\\/lib -LD:\SVN\Octave\test\OCTAVE~1\OCTAVE~1\mingw64\\/qt5/lib -Wl,--export-all-symbols


This trick doesn't work if `prefix` doesn't match in the original flag because the used paths aren't normalized.
E.g.:

$ mkoctfile -p FLIBS
 -LD:\SVN\Octave\test\OCTAVE~1\OCTAVE~1\mingw64\\/lib -LD:\SVN\Octave\test\OCTAVE~1\OCTAVE~1\mingw64\\/qt5/lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-stable/usr/lib/gcc/x86_64-w64-mingw32/9.3.0 -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-stable/usr/lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/lib/../lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-stable/usr/lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/lib -lm -lgfortran -lmingw32 -lmoldname -lmingwex -lmsvcrt -lquadmath -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32


Octave doesn't start for me on Windows atm (unrelated bug #59189). So I haven't tested if this change allows to build Octave Forge packages that previously failed.

(file #49867)

Markus Mützel <mmuetzel>
Group administrator
Fri 25 Sep 2020 12:32:37 AM UTC, comment #3: 

Maybe not foolproof, but this might be a good place to start:


octave --eval '__octave_config_info__ ()' | grep scratch


It would be nice to do something similar for mkoctfile but I don't see an easy way.

Incidentally, there is a message in the code that LFLAGS is to be removed in version 7.1.  We should make that change on the development branch right now so that we uncover any problems with the change well ahead of the release date.

Rik <rik5>
Group administrator
Thu 24 Sep 2020 02:33:26 PM UTC, comment #2: 

Hey, at least it doesn't report something with "/home/jwe/..." now!  :-)

More generally, it would be great to find and replace "/scratch/build/..." wherever we can with the directories that are appropriate for location on the system where Octave is installed and running, not where it was built.  This instance in mkoctfile is probably not the only place where this error occurs.

John W. Eaton <jwe>
Group administrator
Thu 24 Sep 2020 02:15:12 PM UTC, comment #1: 

Does it in octave 5.2 as well

John Donoghue <lostbard>
Group Member
Wed 23 Sep 2020 08:35:33 PM UTC, original submission:  

With the release candidate Octave 6.0.90, I see the following:

>> mkoctfile -p LDFLAGS
-Wl,-rpath-link,/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib -L/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/qt5/lib -Wl,--export-all-symbols


These seem to be the linker flags that would be valid on the platform where Octave was built.

The LFLAGS emit a deprecation warning but seem to be (more) correct for the platform where Octave is installed and running:

>> mkoctfile -p LFLAGS
warning: LFLAGS is deprecated and will be removed in a future version of Octave, use LDFLAGS instead
-LC:\PROGRA~1\GNUOCT~1\OCTAVE~1.90\mingw64\lib\octave\6.0.90 -LC:\PROGRA~1\GNUOCT~1\OCTAVE~1.90\mingw64\lib


Markus Mützel <mmuetzel>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #49895:  of-control-1-LDFLAGS.patch added by mmuetzel (1KiB - application/octet-stream)
file #49891:  bug59173_1-mkoctfile_LDFLAGS_default.patch added by mmuetzel (2KiB - application/octet-stream)
file #49890:  bug59173_mkoctfile_LDFLAGS_v3.patch added by mmuetzel (4KiB - application/octet-stream)
file #49889:  bug59173_mkoctfile_LDFLAGS_v2.patch added by mmuetzel (2KiB - application/octet-stream)
file #49881:  59173.cset added by rik5 (3KiB - application/octet-stream)
file #49867:  bug59173_mkoctfile_prefix.patch added by mmuetzel (11KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 20 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-10-25 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2020-10-20 jwe StatusIn Progress Ready For Test
    2020-10-19 jwe StatusFixed In Progress
        Open/ClosedClosed Open
    2020-10-10 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2020-10-09 mmuetzel StatusIn Progress Ready For Test
    2020-10-07 rik5 Summary&quot;mkoctfile -p&quot; returns wrong LDFLAGS on Windows "mkoctfile -p" returns wrong values for certain flags on cross-built systems (Windows)
    2020-10-07 mmuetzel StatusPatch Reviewed In Progress
    2020-09-30 rik5 StatusPatch Submitted Patch Reviewed
    2020-09-30 mmuetzel Attached File- Added of-control-1-LDFLAGS.patch, #49895
    2020-09-30 mmuetzel Attached File- Added bug59173_1-mkoctfile_LDFLAGS_default.patch, #49891
        Attached File- Added bug59173_2-mkoctfile_DL_LDFLAGS_default.patch, #49892
        Attached File- Added bug59173_3-mkoctfile_LDFLAGS_last_stable.patch, #49893
    2020-09-29 mmuetzel Attached File- Added bug59173_mkoctfile_LDFLAGS_v3.patch, #49890
    2020-09-29 mmuetzel Attached File- Added bug59173_mkoctfile_LDFLAGS_v2.patch, #49889
    2020-09-28 rik5 Attached File- Added 59173.cset, #49881
        StatusNone Patch Submitted
    2020-09-27 mmuetzel Attached File- Added bug59173_mkoctfile_prefix.patch, #49867

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code