bugGNU Octave - Bugs: bug #53920, mkoctfile tries to link with...


bug #53920: mkoctfile tries to link with /scratch/build/.../libiconv.dll.a

Submitter:  Fred Hoeve <fredh>
Submitted:  Wed 16 May 2018 08:09:56 AM UTC
Category:  Octave Function Severity:  4 - Important
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Fixed Assigned to:  None
Originator Name:  Fred H Open/Closed:  * Closed
Release:  * 4.4.0 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Wed 11 Jul 2018 08:34:31 PM UTC, comment #12: 

I tested a build of the current stable sources and it seems to handle the example from the original submission correctly.

John W. Eaton <jwe>
Group administrator
Wed 11 Jul 2018 04:32:17 PM UTC, comment #11: 

I couldn't see any way to get the configure code from gnulib to work differently, or to override its behavior using cache variables.  So for now I pushed this change to stable and merged with default.  Is this enough to fix the problem reported here?


I haven't finished and tested a new build yet, but it appears that mkoctfile.cc does now have -liconv substituted instead of /path/to/libiconv.dll.a, so I think it should work.

A separate issue that I didn't fix yet is variables in mkoctfile have -LDIR variables that are from the build system but are not transformed to be correct for the location where Octave is ultimately installed.  However, I think GCC will find all the libraries and header files that are needed, even with these incorrect -L options.  However, it would be nice to remove duplicates and transform them based on the value of OCTAVE_HOME.

John W. Eaton <jwe>
Group administrator
Mon 21 May 2018 12:44:22 PM UTC, comment #10: 

You can override the OCTAVE_LINK_DEPS value by setting it with set env:

setenv('OCTAVE_LINK_DEPS', "-lfreetype -lhdf5 -lGraphicsMagick++ -lGraphicsMagick -lz -lfftw3 -lfftw3f \
-lopengl32 -lglu32 -lfontconfig -lfreetype    -lgl2ps  -ladvapi32 -llapack -lcurl -lcholmod -lumfpack \
-lamd -lcamd -lcolamd -lccolamd -lcxsparse -lsuitesparseconfig -larpack -lqrupdate -lopenblas \
-lreadline -ltermcap  -lpcre  -lm -lgfortran -lmingw32 -lmoldname \
-lmingwex -lmsvcrt -lquadmath -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -lpsapi -lgdi32 \
-lm -lws2_32 -lws2_32   -ladvapi32  -lws2_32 -lws2_32 -liconv")

John Donoghue <lostbard>
Group Member
Thu 17 May 2018 09:45:49 PM UTC, comment #9: 

Hi Fred - this is a bug tracker, not a support tracker. Your contributions will be very welcome if you have suggestions or patches to help fix this bug that you have brought to our attention.

Mike Miller <mtmiller>
Group Member
Thu 17 May 2018 02:10:09 PM UTC, comment #8: 

Hi, not sure if I understand all your comments. Do i have to change a setting to get mkoctfile working ? If so, please tell me how to do this.  Thanks

Fred Hoeve <fredh>
Thu 17 May 2018 03:05:35 AM UTC, comment #7: 

if I read lib-link.m4 correctly, since it is finding a .a file, it is treating it as a static lib and hence using the full path, rather than the I guess a special case? where its really a stub for the dll.

John Donoghue <lostbard>
Group Member
Wed 16 May 2018 09:05:24 PM UTC, comment #6: 

That is all correct information. On a typical GNU/Linux system, the iconv function is included in glibc, so both LIBICONV and LTLIBICONV should be empty.

It is also correct that Octave builds itself using the Libtool variant LTLIBICONV, but uses the non-Libtool variant LIBICONV when embedding the string into mkoctfile.

The only thing that is incorrect about this is that Gnulib's code for checking for libiconv is embedding the fixed path to the library into LIBICONV. The logic for all of this is in Gnulib's AC_LIB_LINKFLAGS macro (lib-link.m4).

Mike Miller <mtmiller>
Group Member
Wed 16 May 2018 08:41:23 PM UTC, comment #5: 

and in configure.ac,



John Donoghue <lostbard>
Group Member
Wed 16 May 2018 08:38:25 PM UTC, comment #4: 

I'm not sure how libtool vs the rest works, but for reference, when looking in config.log when cross building octave for windows.

LTLIBICONV = -L/thelibpath -liconv -R/thelibpath

LIBICONV = /thelibpath/libiconv.dll.a -L/thelibpath

On my native fedora build:


John Donoghue <lostbard>
Group Member
Wed 16 May 2018 08:20:36 PM UTC, comment #3: 

I added the gnulib module here:

I am seeing the following during bootstrap:

You may need to use the following Makefile variables when linking.
Use them in <program>_LDADD when linking a program, or
in <library>_a_LDFLAGS or <library>_la_LDFLAGS when linking a library.
  $(LTLIBICONV) when linking with libtool, $(LIBICONV) otherwise

I didn't touch the makefile (or configure fwiw). Does something need to be changed in those as well?

Markus M├╝tzel <mmuetzel>
Group administrator
Wed 16 May 2018 06:30:08 PM UTC, comment #2: 

In the config.log

configure:41844: checking how to link with libiconv
configure:41846: result: /scratch/build/mxe-octave-w64-32-stable/usr/x86_64-w64-mingw32/lib/libiconv.dll.a -L/scratch/build/mxe-octave-w64-32-stable/usr/x86_64-w64-mingw32/lib

The check for libiconv comes directly from Gnulib, but maybe there is a cache variable or an option that can be used to influence the result here.

Mike Miller <mtmiller>
Group Member
Wed 16 May 2018 04:06:12 PM UTC, comment #1: 

Running on mine, libiconv wasn't being included on 4.2.2, so was never an issue. The -I and -L parts are mix of the build and the current config in both versions.

In 4.4, iconv is being added to the dependant libs, but in this case is that it is using the full path to the libiconv.dll.a file instead of using a -liconv or equivalent.

Running mkoctfile -p OCTAVE_LINK_DEPS (in 4.4) shows it as the only library being used that way.

John Donoghue <lostbard>
Group Member
Wed 16 May 2018 08:09:56 AM UTC, original submission:  

If I specify the command
mkoctfile --link-stand-alone standalone.cc -o standalone.exe -verbose
 then got the message
g++: error: /scratch/build/mxe-octave-w64-32-stable/usr/x86_64-w64-mingw32/lib/libiconv.dll.a: No
 such file or directory

In 4.2.2 the library and include was set to the installation folder, e.g. c:\octave4.2.2\....

Code standalone.cc

#include <iostream>
#include <octave/oct.h>

main (void)
  std::cout << "Hello Octave world!\n";

  int n = 2;
  Matrix a_matrix = Matrix (n, n);

  for (octave_idx_type i = 0; i < n; i++)
    for (octave_idx_type j = 0; j < n; j++)
      a_matrix(i,j) = (i + 1) * 10 + (j + 1);

  std::cout << a_matrix;

  return 0;

Fred Hoeve <fredh>


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

Attach Files:

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 rik5 (Updated the item)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by fredh (Submitted the item)
  • -email is unavailable- added by fredh (Octave mkoctfile)

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

    Date Changed by Updated Field Previous Value => Replaced by
    2018-07-28 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2018-07-11 jwe StatusConfirmed Ready For Test
    2018-07-11 jwe StatusReady For Test Confirmed
    2018-07-11 jwe StatusConfirmed Ready For Test
    2018-05-16 mtmiller Severity3 - Normal 4 - Important
        Item GroupNone Unexpected Error or Warning
        StatusNone Confirmed
        Summarymkoctfile, include and lib paths are wrong mkoctfile tries to link with /scratch/build/.../libiconv.dll.a
    2018-05-16 fredh Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code