bugGNU Octave - Bugs: bug #49548, mkoctfile fails to link Fortran...

 
 

bug #49548: mkoctfile fails to link Fortran sources without -lgfortran on Windows

Submitted by:  None
Submitted on:  Sun 06 Nov 2016 09:46:34 PM UTC  
 
Category:  Configuration and Build System Severity:  2 - Minor
Priority:  3 - Low Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  dev
Operating System:  Microsoft Windows

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)

Fri 07 Feb 2020 04:48:12 PM UTC, comment #16: 

@Mike: I added a commit message and pushed the change under your name here: https://hg.savannah.gnu.org/hgweb/octave/rev/42921bff241a.

I'm not sure anyone does standalone stuff on Windows, or even whether it can be done, so I'm going to close this report.  If there are, indeed, programmers who want this capability they can file a new bug report.

Rik <rik5>
Project Administrator
Thu 06 Feb 2020 08:58:36 PM UTC, comment #15: 

Sure, I think you're right.

I'm wary of overwriting the FLIBS variable to be empty.

Maybe something like

      std::string cmd = ...
      ...
#if defined (OCTAVE_USE_WINDOWS_API) || defined(CROSS)
      if (! f77files.empty ())
        cmd += ' ' + vars["FLIBS"];
#endif

Patch attached for comment and testing.

Does anyone build stand-alone programs on Windows, and do we also need to add FLIBS to the link line for that case?

(file #48365)

Mike Miller <mtmiller>
Project Administrator
Thu 06 Feb 2020 05:06:43 PM UTC, comment #14: 

@Mike: Can you comment on my suggestion in comment #13?

Rik <rik5>
Project Administrator
Tue 31 Dec 2019 03:57:43 PM UTC, comment #13: 

This is tedious, but maybe we need to change mkoctfile link with Fortran libraries explicitly when doing the link step.  The code is in src/mkoctfile.in.cc.  At the very bottom the link step is done:

    {
#if defined (OCTAVE_USE_WINDOWS_API) || defined(CROSS)
      octave_libs = "-L" + quote_path (vars["OCTLIBDIR"])
                  + ' ' + vars["OCTAVE_LIBS"];
#endif

      std::string cmd
        = (vars["CXXLD"] + ' ' + vars["ALL_CXXFLAGS"] + ' '
           + vars["DL_LDFLAGS"] + ' ' + vars["LDFLAGS"] + ' ' + pass_on_options
           + " -o " + octfile + ' ' + objfiles + ' ' + libfiles + ' '
           + ldflags + ' ' + vars["LFLAGS"] + ' ' + octave_libs + ' '
           + vars["OCT_LINK_OPTS"] + ' ' + vars["OCT_LINK_DEPS"]);

      int status = run_command (cmd, printonly);

You can see that we already have a special workaround for adding the path to the Octave libraries on Windows.  The list of Fortran files is in the variable f77files so some pseudocode might be

if (! f77files.empty ())
{
  ... Do Something Special
}

Someone like Mike Miller who is good at build systems should probably comment.  I could see this as a possible block.

if (f77files.empty ())
  vars["FLIBS"] = "";

And then change the link command to use FLIBS

      std::string cmd
        = (vars["CXXLD"] + ' ' + vars["ALL_CXXFLAGS"] + ' '
           + vars["DL_LDFLAGS"] + ' ' + vars["LDFLAGS"] + ' ' + pass_on_options
           + " -o " + octfile + ' ' + objfiles + ' ' + libfiles + ' '
           + ldflags + ' ' + vars["LFLAGS"] + ' ' + octave_libs + ' '
           + vars["OCT_LINK_OPTS"] + ' ' + vars["OCT_LINK_DEPS"]
           + ' ' + vars["FLIBS"]);

Or, if we want to really isolate Windows from other systems you could place the entire link command under #ifdef protection such as

#if defined (OCTAVE_USE_WINDOWS_API) || defined(CROSS)
      octave_libs = "-L" + quote_path (vars["OCTLIBDIR"])
                  + ' ' + vars["OCTAVE_LIBS"];

      std::string cmd
        = (vars["CXXLD"] + ' ' + vars["ALL_CXXFLAGS"] + ' '
           + vars["DL_LDFLAGS"] + ' ' + vars["LDFLAGS"] + ' ' + pass_on_options
           + " -o " + octfile + ' ' + objfiles + ' ' + libfiles + ' '
           + ldflags + ' ' + vars["LFLAGS"] + ' ' + octave_libs + ' '
           + vars["OCT_LINK_OPTS"] + ' ' + vars["OCT_LINK_DEPS"]
           + ' ' + vars["FLIBS"]);

#else
      std::string cmd
        = (vars["CXXLD"] + ' ' + vars["ALL_CXXFLAGS"] + ' '
           + vars["DL_LDFLAGS"] + ' ' + vars["LDFLAGS"] + ' ' + pass_on_options
           + " -o " + octfile + ' ' + objfiles + ' ' + libfiles + ' '
           + ldflags + ' ' + vars["LFLAGS"] + ' ' + octave_libs + ' '
           + vars["OCT_LINK_OPTS"] + ' ' + vars["OCT_LINK_DEPS"]);
#endif

Rik <rik5>
Project Administrator
Tue 31 Dec 2019 12:52:38 PM UTC, comment #12: 

There was a bug for the tisan package https://savannah.gnu.org/bugs/?45815, that looks like was for the same issue.

The package makefile was expicitly changed so that it gets the fortran libs and uses them for windows/cygwin

The control package does the same but uses the explicit flags for all OSs.

John Donoghue <lostbard>
Project Member
Tue 31 Dec 2019 06:29:29 AM UTC, comment #11: 

In comment #10 the example for Octave 4.4.1, I forgot to export the correct LD_LIBRARY_PATH, thus

        liboctinterp.so.6 => not found
        liboctave.so.6 => not found

is not "true" and looks as verbose as for 4.2.2, because of the transient dependencies of those.

Kai Torben Ohlhus <siko1056>
Project Member
Tue 31 Dec 2019 06:25:10 AM UTC, comment #10: 

> @Kai: When you run with '-v' do you see -lgfortran being added to the linkage phase with Octave 4.2.2 and not with Octave 5.1.0?


Yes, comment #8 was explicitly for the three MS Windows versions of Octave.  There "-lgfortran" was explicitly apparent in MS Windows Octave 4.2.2.  If the output is interesting, I can also post it here, but is more verbose than in Linux.

On Linux the linking using "-lgfortran" never happened for those versions.  Here the verbose output for Linux.

$ ./mkoctfile-5.1.0 -v fortrandemo.cc fortransub.f
gfortran -c -fPIC -g -O2 -std=legacy -fdefault-integer-8    fortransub.f -o /tmp/oct-1DrdhX.o
g++ -c -I/home/siko1056/work/octave/install/include -fPIC -I/home/siko1056/work/octave/install/include/octave-5.1.0/octave/.. -I/home/siko1056/work/octave/install/include/octave-5.1.0/octave -I/home/siko1056/work/octave/install/include  -pthread -fopenmp -g -O2    fortrandemo.cc -o /tmp/oct-f0vX3r.o
g++ -I/home/siko1056/work/octave/install/include/octave-5.1.0/octave/.. -I/home/siko1056/work/octave/install/include/octave-5.1.0/octave -I/home/siko1056/work/octave/install/include  -pthread -fopenmp -g -O2 -shared -Wl,-Bsymbolic -L/home/siko1056/work/octave/install/lib  -o fortrandemo.oct  /tmp/oct-1DrdhX.o /tmp/oct-f0vX3r.o    -L/home/siko1056/work/octave/install/lib  -L/home/siko1056/work/octave/install/lib


$ ldd fortrandemo.oct
        linux-vdso.so.1 (0x00007ffe8ce8b000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f53dfaa1000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f53df769000)
        libgomp.so.1 => /usr/lib64/libgomp.so.1 (0x00007f53df539000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f53df321000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f53df103000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f53ded49000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f53e0030000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f53deb45000)

./mkoctfile-4.4.1 -v fortrandemo.cc fortransub.f
gfortran -c -fPIC -g -O2 -fdefault-integer-8    fortransub.f -o fortransub.o
g++ -c -I/home/siko1056/work/octave/install/include -fPIC -I/home/siko1056/work/octave/install/include/octave-4.4.1/octave/.. -I/home/siko1056/work/octave/install/include/octave-4.4.1/octave -I/home/siko1056/work/octave/install/include  -pthread -fopenmp -g -O2    fortrandemo.cc -o fortrandemo.o
g++ -I/home/siko1056/work/octave/install/include/octave-4.4.1/octave/.. -I/home/siko1056/work/octave/install/include/octave-4.4.1/octave -I/home/siko1056/work/octave/install/include  -pthread -fopenmp -g -O2 -shared -Wl,-Bsymbolic  -o fortrandemo.oct  fortransub.o fortrandemo.o   -L/home/siko1056/work/octave/install/lib/octave/4.4.1 -L/home/siko1056/work/octave/install/lib -loctinterp -loctave -L/home/siko1056/work/octave/install/lib

$ ldd fortrandemo.oct
        linux-vdso.so.1 (0x00007ffd77ba0000)
        liboctinterp.so.6 => not found
        liboctave.so.6 => not found
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007ff705dbe000)
        libm.so.6 => /lib64/libm.so.6 (0x00007ff705a86000)
        libgomp.so.1 => /usr/lib64/libgomp.so.1 (0x00007ff705856000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff70563e000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff705420000)
        libc.so.6 => /lib64/libc.so.6 (0x00007ff705066000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff70634e000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007ff704e62000)

$ ./mkoctfile-4.2.2 -v fortrandemo.cc fortransub.f
gfortran -c -fPIC -g -O2 -fdefault-integer-8    fortransub.f -o fortransub.o
g++ -c -I/home/siko1056/work/octave/install/include -fPIC -I/home/siko1056/work/octave/install/include/octave-4.2.2/octave/.. -I/home/siko1056/work/octave/install/include/octave-4.2.2/octave -I/home/siko1056/work/octave/install/include  -pthread -fopenmp -g -O2    fortrandemo.cc -o fortrandemo.o
g++ -I/home/siko1056/work/octave/install/include/octave-4.2.2/octave/.. -I/home/siko1056/work/octave/install/include/octave-4.2.2/octave -I/home/siko1056/work/octave/install/include  -pthread -fopenmp -g -O2 -shared -Wl,-Bsymbolic  -o fortrandemo.oct  fortransub.o fortrandemo.o   -L/home/siko1056/work/octave/install/lib/octave/4.2.2 -L/home/siko1056/work/octave/install/lib -loctinterp -loctave -L/home/siko1056/work/octave/install/lib

$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/siko1056/work/octave/install/lib/octave/4.2.2

$ ldd fortrandemo.oct                                              linux-vdso.so.1 (0x00007ffe7f3b7000)
        liboctinterp.so.4 => /home/siko1056/work/octave/install/lib/octave/4.2.2/liboctinterp.so.4 (0x00007f2d81cfd000)
        liboctave.so.4 => /home/siko1056/work/octave/install/lib/octave/4.2.2/liboctave.so.4 (0x00007f2d80aa2000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f2d80718000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f2d803e0000)
        libgomp.so.1 => /usr/lib64/libgomp.so.1 (0x00007f2d801b0000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2d7ff98000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2d7fd7a000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f2d7f9c0000)
        libhdf5.so.103 => /usr/lib64/libhdf5.so.103 (0x00007f2d7f42d000)
        libGraphicsMagick++-Q16.so.12 => /usr/lib64/libGraphicsMagick++-Q16.so.12 (0x00007f2d7f1b8000)
        libGraphicsMagick-Q16.so.3 => /usr/lib64/libGraphicsMagick-Q16.so.3 (0x00007f2d7ede0000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f2d7ebc9000)
        libfftw3.so.3 => /usr/lib64/libfftw3.so.3 (0x00007f2d7e7c3000)
        libfftw3f.so.3 => /usr/lib64/libfftw3f.so.3 (0x00007f2d7e447000)
        libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f2d7e1b6000)
        libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00007f2d7df49000)
        libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f2d7dd04000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f2d7da5d000)
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f2d7d71c000)
        libgl2ps.so.1 => /usr/lib64/libgl2ps.so.1 (0x00007f2d7d506000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007f2d7d303000)
        libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x00007f2d7d07a000)
        libcholmod.so.3 => /home/siko1056/work/octave/install/lib/libcholmod.so.3 (0x00007f2d7cd6c000)
        libumfpack.so.5 => /home/siko1056/work/octave/install/lib/libumfpack.so.5 (0x00007f2d7ca9c000)
        libamd.so.2 => /home/siko1056/work/octave/install/lib/libamd.so.2 (0x00007f2d7c890000)
        libcamd.so.2 => /home/siko1056/work/octave/install/lib/libcamd.so.2 (0x00007f2d7c683000)
        libcolamd.so.2 => /home/siko1056/work/octave/install/lib/libcolamd.so.2 (0x00007f2d7c47b000)
        libccolamd.so.2 => /home/siko1056/work/octave/install/lib/libccolamd.so.2 (0x00007f2d7c26f000)
        libcxsparse.so.3 => /home/siko1056/work/octave/install/lib/libcxsparse.so.3 (0x00007f2d7c03b000)
        libsuitesparseconfig.so.5 => /home/siko1056/work/octave/install/lib/libsuitesparseconfig.so.5 (0x00007f2d7be38000)
        libarpack.so.2 => /home/siko1056/work/octave/install/lib/libarpack.so.2 (0x00007f2d7bbe8000)
        libqrupdate.so.1 => /home/siko1056/work/octave/install/lib/libqrupdate.so.1 (0x00007f2d7b9ca000)
        libopenblas.so.0 => /home/siko1056/work/octave/install/lib/libopenblas.so.0 (0x00007f2d79bbf000)
        libreadline.so.7 => /lib64/libreadline.so.7 (0x00007f2d79970000)
        libncurses.so.6 => /lib64/libncurses.so.6 (0x00007f2d79747000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f2d79543000)
        libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007f2d792b6000)
        libgfortran.so.4 => /usr/lib64/libgfortran.so.4 (0x00007f2d78ee2000)
        libquadmath.so.0 => /usr/lib64/libquadmath.so.0 (0x00007f2d78ca2000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f2d8313b000)
        liblcms2.so.2 => /usr/lib64/liblcms2.so.2 (0x00007f2d78a47000)
        libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f2d78835000)
        libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x00007f2d78618000)
        libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x00007f2d7840e000)
        libGLX.so.0 => /usr/lib64/libGLX.so.0 (0x00007f2d781dc000)
        libGLdispatch.so.0 => /usr/lib64/libGLdispatch.so.0 (0x00007f2d77f26000)
        libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f2d77cf4000)
        libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f2d77ab1000)
        libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f2d77888000)
        libnghttp2.so.14 => /usr/lib64/libnghttp2.so.14 (0x00007f2d77661000)
        libidn2.so.0 => /usr/lib64/libidn2.so.0 (0x00007f2d77444000)
        libssh.so.4 => /usr/lib64/libssh.so.4 (0x00007f2d771c3000)
        libpsl.so.5 => /usr/lib64/libpsl.so.5 (0x00007f2d76fb3000)
        libssl.so.1.1 => /usr/lib64/libssl.so.1.1 (0x00007f2d76d47000)
        libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007f2d768b9000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007f2d7666d000)
        libldap_r-2.4.so.2 => /usr/lib64/libldap_r-2.4.so.2 (0x00007f2d76419000)
        liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f2d7620a000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f2d76002000)
        libmetis.so => /home/siko1056/work/octave/install/lib/libmetis.so (0x00007f2d75d93000)
        libcudart.so.10.1 => /usr/local/cuda-10.1/lib64/libcudart.so.10.1 (0x00007f2d75b17000)
        libcublas.so.10 => /usr/lib64/libcublas.so.10 (0x00007f2d71861000)
        libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f2d71633000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f2d7142f000)
        libunistring.so.2 => /usr/lib64/libunistring.so.2 (0x00007f2d710ad000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007f2d70dd1000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007f2d70b9f000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f2d7099b000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007f2d7078e000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f2d70577000)
        libsasl2.so.3 => /usr/lib64/libsasl2.so.3 (0x00007f2d7035a000)
        libcublasLt.so.10 => /usr/lib64/libcublasLt.so.10 (0x00007f2d6e4c7000)
        libkeyutils.so.1 => /usr/lib64/libkeyutils.so.1 (0x00007f2d6e2c3000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f2d6e09a000)

Kai Torben Ohlhus <siko1056>
Project Member
Mon 30 Dec 2019 10:07:29 PM UTC, comment #9: 

@Kai: When you run with '-v' do you see -lgfortran being added to the linkage phase with Octave 4.2.2 and not with Octave 5.1.0?

I'm interested in whether Octave use to add the flag, or whether the gfortran package used to add it and no longer does.

Also, given that the 6.1 release is close, I've marke this as related to the "dev" release.  Can you test mkoctfile with a development version to see if the problem is still present there?

Rik <rik5>
Project Administrator
Sat 28 Dec 2019 05:35:44 AM UTC, comment #8: 

Unfortunately, there some regression happened.

Compiling Octave's Fortran example "fortrandemo.cc" (bottom of https://octave.org/doc/v5.1.0/Calling-External-Code-from-Oct_002dFiles.html) with the command from comment #5 works on

Octave 4.2.2

where "mkoctfile -v" shows that "-lgfortran" is used automatically. "-lgfortran" is not automatically linked in

Octave 4.4.1
Octave 5.1.0

Kai Torben Ohlhus <siko1056>
Project Member
Wed 09 Nov 2016 09:37:57 PM UTC, comment #7: 

@Dmitar: Thank you for the kind words.  I recommend you upgrade to 4.2.0 as soon as it is released as there have been a lot of improvements.  Closing report.

Rik <rik5>
Project Administrator
Wed 09 Nov 2016 08:21:50 PM UTC, comment #6: 

Dear Rik,

I found the external code interface of Octave to provide a useful tool for reuse of existing code. In this means I would like to learn more about how to use it. My first step was to try the example from the manual. It did not work. That was problematic for me because of lack of experience at the beginning. This ‘pseudo-bug’ taught me a lot and now I can enjoy the programming with Octave.

Thank you for your help and effort!
Yours sincerely
Dimitar

Dimitar <delaplace>
Tue 08 Nov 2016 11:25:03 PM UTC, comment #5: 

Is this still a problem?  I tested with the the latest 4.2.0-rc3 candidate in a Windows XP virtual machine and the original compilation command worked fine.

mkoctfile -v fortrandemo.cc fortransub.f

I'm pretty sure the version of gcc that is shipped with Octave has been upgraded from 4.0.3 to 4.2.0 and this is probably making the difference.

Rik <rik5>
Project Administrator
Tue 08 Nov 2016 06:38:29 PM UTC, comment #4: 

Updated the summary to reflect the problem. Since there is an easy workaround I'm lowering the priority, but this looks like it could be done easily in mkoctfile. And maybe should only be done on systems where this overlinking of dynamic objects is required.

Mike Miller <mtmiller>
Project Administrator
Tue 08 Nov 2016 04:12:34 PM UTC, comment #3: 

Dear Mr Miller,

I thank you for the useful comment.
After applying of the correct command line mkoctfile works properly under Windows 8.1.
Below you can find the output of Octave GUI:

>> mkoctfile -v fortrandemo.cc fortransub.f -lgfortran


gfortran -c  -O -mieee-fp     fortransub.f -o fortransub.o

g++ -c -I/scratch/jwe/mxe-octave/usr/i686-w64-mingw32/include  -IC:\Octave\Octave-4.0.3
\include\octave-4.0.3\octave\.. -IC:\Octave\Octave-4.0.3\include\octave-4.0.3\octave -I
C:\Octave\Octave-4.0.3\include -pthread -mieee-fp -g -O2    fortrandemo.cc -o fortrandemo.o

g++ -IC:\Octave\Octave-4.0.3\include\octave-4.0.3\octave\.. -IC:\Octave\Octave-4.0.3\in
clude\octave-4.0.3\octave -IC:\Octave\Octave-4.0.3\include -pthread -mieee-fp -g -O2 -shared -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc  -o fortrandemo.oct  fortransub.o fortrandemo.o   -lgfortran -LC:\Octave\Octave-4.0.3\lib\octave\4.0.3 -LC:\Octave\Octave-4.0.3\lib -loctinterp -loctave -Wl,-rpath-link,/scratch/jwe/mxe-octave/usr/i686-w64-mingw32/lib -L/scratch/jwe/mxe-octave/usr/i686-w64-mingw32/lib -Wl,--export-all-symbols

>> fortrandemo(1:3)

ans =

   1.00000   0.50000   0.33333

>> [b, s] = fortrandemo (1:3)

b =

   1.00000   0.50000   0.33333

s = There are   3 values IN the input vector

Yours sincerely
Dimitar

Dimitar <delaplace>
Mon 07 Nov 2016 07:26:13 PM UTC, comment #2: 

This may be a difference in the way shared objects are linked differently between operating systems. On my Debian system I am able to build an oct file from a myfunc.cc and a mysub.f without explicitly needing to link in libgfortran. As I understand it it works for me because shared objects do not need to resolve all of the symbols that they use, they only need to be resolved at the point when the shared object is loaded by the executable. This may be different on Windows.

Just so it's clear what the problem is, are you able to build this oct file on your system with the following command

>> mkoctfile -v fortrandemo.cc fortransub.f -lgfortran

Adding the -lgfortran is not necessary on GNU/Linux systems, but it does no harm either. Does it solve the problem for you?

Mike Miller <mtmiller>
Project Administrator
Mon 07 Nov 2016 11:27:56 AM UTC, comment #1: 

I think a better description of the problem should be:
'mkoctfile can not link correctly C++ respectively C and FORTRAN compiled sources together.'

Dimitar <delaplace>
Sun 06 Nov 2016 09:46:34 PM UTC, original submission:  

Dear software developer,

I’m using Octave version 4.0.3 on Windows 8.1 (x64) and found the following bug.
I tried to program the example from appendix ‘A.1.9 Calling External Code from Oct-Files’ of ‘octave.pdf’ manual. The direct usage of mkoctfile command from the Octave-GUI don’t yields the expected result as described in the manual. Thus, Octave should automate ‘this by providing the mkoctfile command with which to build oct-files’. However this automation does not work currently. That is the bug.
As solution I take ‘--verbose’ of the command and after that with the help of Octave bash shell by ‘try and error’ I find out the correct input. You can find it below:

$ gfortran -Wall -c  -O -mieee-fp   fortransub.f -o fortransub.o

$ g++ -Wall -c -I/scratch/jwe/mxe-octave/usr/i686-w64-mingw32/include  -I/C/Octave/Octave-4.0.3/include/octave-4.0.3/octave/..   -I/C/Octave/Octave-4.0.3/include/octave-4.0.3/octave -I/C/Octave/Octave-4.0.3/include  -pthread  -mieee-fp -g -O2  fortrandemo.cc -o fortrandemo.o

$ g++ -Wall -I/C/Octave/Octave-4.0.3/include/octave-4.0.3/octave/.. -I/C/Octave/Octave-4.0.3/include/octave-4.0.3/octave -I/C/Octave/Octave-4.0.3/include -pthread -mieee-fp -g -O2 -shared -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc  -o fortrandemo.oct  fortransub.o fortrandemo.o   -L/C/Octave/Octave-4.0.3/lib/octave/4.0.3 -L/C/Octave/Octave-4.0.3/lib -lliboctinterp -lliboctave  -Wl,-rpath-link,/scratch/jwe/mxe-octave/usr/i686-w64-mingw32/lib -L/scratch/jwe/mxe-octave/usr/i686-w64-mingw32/lib  -Wl,--export-all-symbols –llibgfortran

As shown above there were two main problems. Firstly, the linking of the correct libraries was erroneously: lliboctinterp, lliboctave (llibgfortran is currently missing) and secondly, the backslash of the include paths was wearisome, which I had to edit manually.

There is nothing more to be reported. I hope you will fix this bug, which would be a great help for unprofessional programmer as me.

Thank you for your effort!

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #48365:  flibs.diff added by mtmiller (597B - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by delaplace (Posted a comment)
  •  

    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 20 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-02-07 rik5 StatusPatch Submitted => Fixed
        Open/ClosedOpen => Closed
    2020-02-06 mtmiller Attached File- => Added flibs.diff, #48365
        StatusConfirmed => Patch Submitted
    2020-01-25 mtmiller Carbon-CopyRemoved 80942 => -
    2019-12-30 rik5 Release5.1.0 => dev
    2019-12-28 siko1056 Item GroupIncorrect Result => Regression
        StatusFixed => Confirmed
        Open/ClosedClosed => Open
        Releasedev => 5.1.0
    2016-11-09 rik5 StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2016-11-08 rik5 StatusPostponed => Ready For Test
    2016-11-08 mtmiller Severity3 - Normal => 2 - Minor
        Priority5 - Normal => 3 - Low
        Item GroupBuild Failure => Incorrect Result
        StatusNeed Info => Postponed
        Release4.0.3 => dev
        Summarymkoctfile can not build FORTRAN => mkoctfile fails to link Fortran sources without -lgfortran on Windows
    2016-11-07 mtmiller StatusNone => Need Info

    Back to the top


    Powered by Savane 3.6