Re: [OctDev] Build problems on solaris 2.8 (octave-forge 2004.07.07)

[Paul K. <pki...@us...>]

On Jul 28, 2004, at 10:55 AM, Robert Reutemann wrote:

> Hi
>
> Trying to build the latest octave-forge release
> (2004.07.07) on solaris (sparc) 2.8 using gcc 3.4.1
> with octave 2.1.57 I ran into a couple of problems.

Thanks for reporting them.

> To get through the build process, I had to do
> use the following workarounds. Some of this is
> probably due to the exact setup here, some of
> them might be more general problems.
>
> - /bin/sh versus /bin/bash
>   The octave-forge build seems to assume that /bin/sh
>   actually is a bash shell, which it isn't on a std
>   solaris box.
>   I therefore changed "/bin/sh" to "/bin/bash" in
>   the following places:
>   - Makeconf (SHELL = ...)
>   - all *.sh files in all directories (#!/bin/bash,
>     not #!/bin/sh).

We are trying to be shell agnostic.  Please report
the sh incompatibilities rather than requiring bash
on the target machine.

> - term.h does not compile on solaris if curses.h
>   isn't included first.
>   For this, I commented out the TERM_H and TERMCAP
>   stuff in Makeconf.
>   This should probably be handled better by the
>   configure process, but I don't know enough about
>   that to try to fix it.

I'm very tempted to remove the term dependent
modules unless someone fixes the configure.  I
will ignore it for awhile longer.

>
> - "-R" option in "X_LIBS"
>   My configure sets "-R/usr/openwin/lib" in X_LIBS,
>   which leads to problems since mkoctfile does not
>   accept "-R".
>   I therefore removed the "-R" option from X_LIBS in
>   Makeconf (might lead to problems later on, but
>   at least build should work ...).

This is an octave bug.  Please report it to bu...@oc...

I tried to set it up so that everything that could be
built would be built and the rest ignored.  Is that
not the case?  Maybe I should fail silently ;-)

> - dispatch.cc doesn't compile
>   gcc does not compile the last statement in
>   main/miscellaneous/dispatch.cc
>   ("template std::map<std::string,std::string>;").
>   I therefore commented that out.

I'm using:

	#if defined(__GNUG__)
	template class std::map<std::string,std::string>;
	#endif

I see octave doesn't even use #if defined(__GNUG__)
anymore.

Can you please report the error message.

Did you need to do similar changes in Octave?

Anyone know the correct incantation?

> - installing: install-sh not found due to relative
>   path.
>   install-sh is set with a relative path ("./install-sh")
>   in Makeconf and octinst.sh (INSTALL = ...). This fails
>   when INSTALL is executed in subdirs.
>   I therefore set this to the full absolute path to
>   install-sh in those two definitions.

I'm using autoconf AC_PROG_INSTALL.  Anyone know
how to make it use absolute path?

> With this, I can build and install octave-forge.
>
> gmake check fails (segmentation violation while in
> main/signal). I don't know yet, what other problems
> I still have.

I would be much obliged if you could split up the
make check work so that it only checks a directory
at a time.  At least that way it will minimize the
consequences of a segfault.  You probably don't
want to go down to the level of the individual file
since that will start and restart octave too many
times.  Alternatively, the test program could monitor
progress and restart at the next test after a segfault.

> If anybody has experience with building octave and
> octave-forge on solaris 2.8 with gcc I'll be thankful
> for any hints and better solutions.

Please post your experiences on the octave wiki

	http://wiki.octave.org

Category Install.

- Paul