Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 7277 - octave 2.0.17 won't build
Summary: octave 2.0.17 won't build
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: George Shapovalov (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-08-30 15:09 UTC by James Anderson
Modified: 2003-07-23 18:15 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Anderson 2002-08-30 15:09:18 UTC
the command "emerge octave" fails on my system.  I am still using gcc-2.95.3, so
it tries to build the old octave version 2.0.17.  Here is the output near where
the build fails:

c++ -shared -o liboctave.so pic/Bounds.o pic/CollocWt.o pic/DAE.o pic/DASSL.o
pic/FEGrid.o pic/LinConst.o pic/LPsolve.o pic/LSODE.o pic/NLEqn.o pic/Quad.o
pic/Range.o pic/cmd-hist.o pic/data-conv.o pic/dir-ops.o pic/f2c-main.o
pic/file-ops.o pic/filemode.o pic/getopt.o pic/getopt1.o pic/idx-vector.o
pic/lo-ieee.o pic/lo-mappers.o pic/lo-specfun.o pic/lo-utils.o pic/mach-info.o
pic/mkdir.o pic/oct-alloc.o pic/oct-glob.o pic/oct-term.o pic/pathsearch.o
pic/prog-args.o pic/rename.o pic/rmdir.o pic/str-vec.o pic/tempname.o
pic/tempnam.o pic/Array.o pic/Array2.o pic/Array3.o pic/DiagArray2.o
pic/MArray.o pic/MArray2.o pic/MDiagArray2.o pic/base-lu.o pic/Array-C.o
pic/Array-b.o pic/Array-ch.o pic/Array-i.o pic/Array-d.o pic/Array-s.o
pic/Array-str.o pic/MArray-C.o pic/MArray-ch.o pic/MArray-i.o pic/MArray-d.o
pic/MArray-s.o pic/Array-flags.o pic/CColVector.o pic/CDiagMatrix.o
pic/CMatrix.o pic/CRowVector.o pic/CmplxAEPBAL.o pic/CmplxCHOL.o pic/CmplxDET.o
pic/CmplxHESS.o pic/CmplxLU.o pic/CmplxQR.o pic/CmplxQRP.o pic/CmplxSCHUR.o
pic/CmplxSVD.o pic/EIG.o pic/MArray-misc.o pic/chMatrix.o pic/dColVector.o
pic/dDiagMatrix.o pic/dMatrix.o pic/dRowVector.o pic/dbleAEPBAL.o pic/dbleCHOL.o
pic/dbleDET.o pic/dbleGEPBAL.o pic/dbleHESS.o pic/dbleLU.o pic/dbleQR.o
pic/dbleQRP.o pic/dbleSCHUR.o pic/dbleSVD.o
make[2]: Leaving directory
`/var/tmp/portage/octave-2.0.17/work/octave-2.0.17/liboctave'
make[1]: Leaving directory `/var/tmp/portage/octave-2.0.17/work/octave-2.0.17'
make: *** [all] Error 2

!!! ERROR: The ebuild did not complete successfully.
!!! Function src_compile, Line 17, Exitcode 2
!!! emake failed

!!! emerge aborting on  /usr/portage/app-sci/octave/octave-2.0.17.ebuild .
Comment 1 George Shapovalov (RETIRED) gentoo-dev 2002-09-01 18:23:46 UTC
Hi guys.

James: Thanks for a bug report!

Tod, Nick: I see that you were processing this ebuild, so I would like to ask
for comments (as I am not that familiar with the package):
I can confirm this problem, with the addition, that the place where it breaks
seems to depend on CFLAGS - high optimizations make it break earlier-on, but I
could reproduce the reported problem (looks like during linking) even with only
CFLAGS="-O". And, yea, this happens on a x86 arch (P-III) with a default-1.0
profile.
  The linkage problem may be related to a missing or improper [version]
dependency. Other than that this seems to be an upstream problem. I would
appreciate your comments on what lib might went wrong or was omitted, as I am
not that familiar with the package. I just remerged ncurses and gnuplot (the
only ones besides glibc listed in DEPEND) and got the same result.

George
Comment 2 Tod M. Neidt (RETIRED) gentoo-dev 2002-09-03 10:27:12 UTC
Hi!

I just merged octave-2.0.17 with no problems.  (That doesn't help much does it).

The state of my system:

CHOST="i686-pc-linux-gnu"
CFLAGS="-march-i686 -O3 -pipe"
CXXFLAGS="${CFLAGS}"

gcc-2.95.3
glibc-2.2.5-r2
ncurses-5.2.20020511
gnuplot-3.7.1.r3

An "ldd /usr/bin/octave" gives

	liboctinterp.so => /usr/lib/octave-2.0.17/liboctinterp.so (0x40017000)
	liboctave.so => /usr/lib/octave-2.0.17/liboctave.so (0x401b6000)
	libcruft.so => /usr/lib/octave-2.0.17/libcruft.so (0x4028a000)
	libm.so.6 => /lib/libm.so.6 (0x403a4000)
	libncurses.so.5 => /lib/libncurses.so.5 (0x403c6000)
	libdl.so.2 => /lib/libdl.so.2 (0x4040b000)
	libstdc++-libc6.2-2.so.3 =>
/usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/libstdc++-libc6.2-2.so.3 (0x4040e000)
	libc.so.6 => /lib/libc.so.6 (0x4045f000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Regards,

tod
Comment 3 Nick Hadaway 2002-09-03 10:50:59 UTC
I have updated the ebuild to use econf and changed emake to make.  The updated 
ebuild should be available in portage within 24 hours.  The version has not 
changed as no functionality was added. octave-2.0.17.ebuild 
 
emerge rsync 
emerge octave 
 
Please let me know if the package emerges for you after the update. 
Comment 4 James Anderson 2002-09-04 08:39:36 UTC
Still will not build.  When I attempt to emerge octave, it dies a lot sooner
than it did before, with the following errors:

gcc -c -DHAVE_CONFIG_H   -I. -I. -I/usr/include -DRL_LIBRARY_VERSION='"2.1"'
-march=i686 -O3 -pipe tilde.c
rm -f libreadline.a
ar cr libreadline.a readline.o vi_mode.o funmap.o keymaps.o parens.o search.o
rltty.o complete.o bind.o isearch.o display.o signals.o util.o kill.o undo.o
macro.o input.o callback.o terminal.o nls.o xmalloc.o history.o histexpand.o
histfile.o histsearch.o shell.o tilde.o
test -n "ranlib" && ranlib libreadline.a
rm -f libhistory.a
ar cr libhistory.a history.o histexpand.o histfile.o histsearch.o shell.o xmalloc.o
test -n "ranlib" && ranlib libhistory.a
make[2]: Leaving directory
`/var/tmp/portage/octave-2.0.17/work/octave-2.0.17/readline'
echo making all in glob
making all in glob
cd glob ; make all
make[2]: Entering directory `/var/tmp/portage/octave-2.0.17/work/octave-2.0.17/glob'
gcc -I. -I. -c \
      -DSTDC_HEADERS=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STRING_H=1
-DHAVE_DIRENT_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRCOLL=1  
-march=i686 -O3 -pipe glob.c -o glob.o
gcc -I. -I. -c \
      -DSTDC_HEADERS=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STRING_H=1
-DHAVE_DIRENT_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRCOLL=1  
-march=i686 -O3 -pipe fnmatch.c -o fnmatch.o
ar rv libglob.a glob.o fnmatch.o
a - glob.o
a - fnmatch.o
ranlib libglob.a
make[2]: Leaving directory `/var/tmp/portage/octave-2.0.17/work/octave-2.0.17/glob'
echo making all in kpathsea
making all in kpathsea
cd kpathsea ; make all
make[2]: Entering directory
`/var/tmp/portage/octave-2.0.17/work/octave-2.0.17/kpathsea'
make[2]: *** No rule to make target `klibtool.config', needed by `tex-file.lo'.
 Stop.
make[2]: Leaving directory
`/var/tmp/portage/octave-2.0.17/work/octave-2.0.17/kpathsea'
make[1]: *** [kpathsea] Error 2
make[1]: Leaving directory `/var/tmp/portage/octave-2.0.17/work/octave-2.0.17'
make: *** [all] Error 2

!!! ERROR: The ebuild did not complete successfully.
!!! Function src_compile, Line -207, Exitcode 2
!!! make failed

!!! emerge aborting on  /usr/portage/app-sci/octave/octave-2.0.17.ebuild .
Comment 5 Nick Hadaway 2002-09-04 09:59:37 UTC
ahhhh... so it is tetex related... i'll test the ebuild with tetex installed... 
Comment 6 George Shapovalov (RETIRED) gentoo-dev 2002-10-25 18:21:48 UTC
Hi guys.

I just retested the octave-2.0.17. It built fine for me except for sandbox
violation issue during install phase, which I corrected in the -r1 ebuild
(committed and keyword-masked). Could you please test and report how it goes?

George
Comment 7 Justin Huff 2002-10-26 02:08:44 UTC
I still get the  smae kpathsea error:
--------------------------------------------
cd kpathsea ; make all
make[2]: Entering directory
`/var/tmp/portage/octave-2.0.17-r1/work/octave-2.0.17/kpathsea'
make[2]: *** No rule to make target `klibtool.config', needed by `tex-file.lo'.
 Stop.
make[2]: Leaving directory
`/var/tmp/portage/octave-2.0.17-r1/work/octave-2.0.17/kpathsea'
make[1]: *** [kpathsea] Error 2
make[1]: Leaving directory `/var/tmp/portage/octave-2.0.17-r1/work/octave-2.0.17'
make: *** [all] Error 2
Comment 8 George Shapovalov (RETIRED) gentoo-dev 2003-02-23 20:35:26 UTC
Hi Justin.

Well, I could not reproduce the problem, but anyway I created a new ebuild 2.0.17-r2, where I added tetex to DEPEND and did some clean-ups (syntactic stuff mostly). Could you please test?

George
Comment 9 Justin Huff 2003-03-14 22:26:03 UTC
Almost there!

--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE = "/tmp/sandbox-octave-2.0.17-3285.log"

mkdir:     /usr/share/octave
mkdir:     /usr/share/octave/2.0.17
mkdir:     /usr/share/octave/2.0.17/m
mkdir:     /usr/share/octave
mkdir:     /usr/share/octave/2.0.17
mkdir:     /usr/share/octave/2.0.17/site
mkdir:     /usr/share/octave/2.0.17/site/m
mkdir:     /usr/share/octave
mkdir:     /usr/share/octave/site
mkdir:     /usr/share/octave/site/m
--------------------------------------------------------------------------------
Comment 10 George Shapovalov (RETIRED) gentoo-dev 2003-03-30 01:43:01 UTC
Hi Justin.

Thanks for testing, though I regret to tell you that that wasn't the righ ebuild ;).
I was trying to recreate your sandbox violation, until I noticed that you were testing 2.0.17, while the "fixed" one is 2.0.17-r2. Looks like -r2 was blocked in the profile :(.

I modified the "pin" in default-1.0 profile to use latest available octave of 2.0.x series. Now you should pick up correct version..
Sorry about the confusion.

George
Comment 11 George Shapovalov (RETIRED) gentoo-dev 2003-04-06 01:32:22 UTC
The latest fix is now stable.

George
Comment 12 Justin Huff 2003-07-02 22:51:46 UTC
I forgot about this.  It works fine now.  Thanks!
Comment 13 George Shapovalov (RETIRED) gentoo-dev 2003-07-22 18:36:18 UTC
Cannot select closed directly, will try reopening..
Comment 14 George Shapovalov (RETIRED) gentoo-dev 2003-07-23 18:15:16 UTC
Hm, I swear I closed it again yesterday. Closing again :).