Mon 05 Sep 2011 12:20:06 AM UTC, comment #14:
For octave-3.4.2,
LIBS='-lgfortran -llapack'
still required at confure stage, while in the dev. source it is not required.
However, I think this post can be closed because one can avoid the link error by setting LIB environmental variable.
|
Mon 05 Sep 2011 12:00:54 AM UTC, comment #13:
Can you compile _contourc_ at this point? This bug is against 3.3.90 and I believe there have been successful compilations of 3.4.2 at this point for MinGW.
|
Mon 21 Feb 2011 11:56:39 PM UTC, comment #12:
Adding extra flag is not required development source. Therefore I think there is a packaging fault and unsolved yet.
|
Mon 21 Feb 2011 11:37:51 PM UTC, comment #11:
Has building _contourc_ on MinGW been resolved with 3.4.0 and using FLIBS="-lgfortran"? The thread seems to indicate that this bug can be closed.
|
Tue 01 Feb 2011 12:18:27 PM UTC, comment #10:
sorry, -lgfortran of course.
Why? Because "determining the fortran libraries" causes a lot of local installation paths end up in FLIBS where they first: don't belong (gcc must know itself where to find it's own libraries) and second: they are valid only for the machine where octave is built - not for any other. As gcc is relocatable (i.e. location independent) and octave is relocatable, such paths should not be part of the configuration information. Otherwise user B, who installs octave to a different path from where I built it when I prepared the installer will see lots of -Lc:\path\to\wherever which are invaild on his machine, and gcc (or ld) complains if you specify a path as search path which does not exist.
|
Tue 01 Feb 2011 10:40:51 AM UTC, comment #9:
I assume you mean FLIBS=-lgfortran, not -gfortran. But in any case, why isn't this detected automatically by the configure script? Or, what does the configure script determine for FLIBS if you don't set it?
|
Tue 01 Feb 2011 10:15:32 AM UTC, comment #8:
I built from tip yesterday, and there was no compilation error (besides the <unistd.h> issue), so no, I can't reproduce this.
I use FLIBS="-gfortran" at configure stage
|
Tue 01 Feb 2011 09:03:54 AM UTC, comment #7:
The same error occurred on octave-3.3.91.
I will send cc. to Benjamin Lindner.
This time I also use
LIBS=-lgfortran -llapack
to avoid error. I am now looking into src/Makefile,am but have not found the origin yet.
Hi Benjamin. Have your tried to build the snapshot in addition to the Mercurial archive?
For the Mercurial archive, I have not met this error.
|
Thu 27 Jan 2011 03:28:25 AM UTC, comment #6:
I have add
LIBS=-lgfortran -llapack
and configure and make again. Build has been successfully carried out.
************************
$ ./run-octave
GNU Octave, version 3.3.90
Copyright (C) 2011 John W. Eaton and others.
<snip>
************************
Build problem lies on only -lgfortran -llapack option was omitted.
I will remove
LIBS=-lgfortran -llapack
and configure and make again and will trace what was wrong.
|
Wed 26 Jan 2011 07:24:43 PM UTC, comment #5:
Thank you for hints.
**********************
spotrf is a function from LAPACK
*********************
Thanks! I will first take a temporary way to add -llapack into the LIBS options to go further.
After the try, I will remove temporary LIBS flag to see what is happening in the detection process.
|
Wed 26 Jan 2011 05:48:53 AM UTC, comment #4:
In each build, precisely which command gave you the error
Is there any difference in the commands used in the two cases?
How about posting what those commands were?
spotrf is a function from LAPACK, so in each of the builds, what did the configure script determine for the BLAS_LIBS and LAPACK_LIBS variables?
In your original report, you said there were errors about missing __gfortran_xxx symbols. That would seem to indicate a problem with detecting Fortran libraries. In each of the builds, what did the configure script determine for the FLIBS variable?
|
Wed 26 Jan 2011 05:33:32 AM UTC, comment #3:
I have compare differences between src/Makefile in the source tree but I could not fine any meaningful differences.
Is there other file to see the differences?
|
Wed 26 Jan 2011 03:02:22 AM UTC, comment #2:
It works for me, so I have no idea what the problem is on your system.
If it also works for you when compiling from the sources in the Mercurial archive, how about comparing what the two builds do to find out what the differences are that might account for the error?
|
Wed 26 Jan 2011 02:31:52 AM UTC, comment #1:
I added a flag
export LIBS='-lgfortran -lgfortranbegin -lm'
and carried out configure again.
Number of errors was reduced but one error remained.
../libcruft/.libs/libranlib.a(setgmn.o):setgmn.f:(.text+0x98): undefined reference to `spotrf_'
Perhaps a linker option is missing.
How do I correct this?
Any suggestions?
|
Wed 26 Jan 2011 12:30:53 AM UTC, original submission:
I have encountered build error of DLD-FUNCTIONS _contourc_ on 3.3.90.
Platform MinGW Complier GCC-4.5.0
#**************
Creating library file: DLD-FUNCTIONS/.libs/__contourc__.dll.a
../libcruft/.libs/libranlib.a(advnst.o):advnst.f:(.text+0x11a): undefined reference to `_gfortran_st_write'
../libcruft/.libs/libranlib.a(advnst.o):advnst.f:(.text+0x132): undefined reference to `_gfortran_transfer_character'
:
:
#**************
The error perhaps is related to the following thread
http://octave.1599824.n4.nabble.com/Force-link-to-local-lib-td3230870.html
Note that the error does not happen for the source on the Mercurial. Something might be wrong at making package.
Regards
Tatsuro
|