[MPlayer-dev-eng] problems with mplayer 1.0pre4 under Solaris 2.8/gcc

[Attila Kinali]

On Wed, Jun 23, 2004 at 04:13:13PM -0400, Ziying Sherwin wrote:
> 
> Dear MPlayer Colleagues,
> 
> Enthused by the limited success of a colleague who built mplayer under
> Solaris, we tried to build MPlayer 1.0pre4 under our Solaris 2.8
> machines using gcc 3.3.
> 
> we ran into many problems, summarized below.  If anyone has insights, we'd be
> grateful to read them.
> 
> 1. If we tried to build mplayer without gui interface, the compilation finished
>    flawlessly. However, then we tried to install it by using command
>       make install
>    the script removed all the binaries, started a new build, then installed the
>    files. Why does that happen? 

Hmm.. sounds like a bug in the Makefile, could you run make with -d 
and tell us what it depends on ?

> Also the installed directory does not contain
>    any conifguration files, e.g. codecs.conf, input.conf and mplayer.conf. How
>    should those files look like?

They are not installed, because they are not needed.
Especialy not codecs.conf as it's compiled in.
For the others, you need them only if you want to achive a special
behavior. Examples (and also the version of codecs.conf used at compile
time) can be found in etc/
But normaly you are better of by not using them at all, MPlayer does the
right thing [tm] by default.


> 2. If we tried to build mplayer with gui interface, the compilation failed.
>    We have libraries like zlib, libpng, libogg and libvorbis installed under
>    directory /depot/package/, symbolic links have been created from each package
>    to /depot/lib and /depot/include. Normally, if we need to compile anything
>    against those libraries, we set LDFLAGS to include "-L/depot/lib" and CFLAGS
>    to include "-I/depot/include". However, if we set those valuables, then
>    run the configure command like:
> 
>       ./configure \
>          --prefix=/depot/package/mplayer_1.0pre3 \
>          --enable-gui
> 
>    We got  error messages during the compilation: (which I have broken up
>    on multiple lines for readability):
> 
>       make[1]: Entering directory `/SOURCE/MPlayer-1.0pre4.gui/libavcodec'
>       gcc -I../libvo/ -I../../libvo -I/depot/include -D_LARGEFILE_SOURCE
>       -D_FILE_OFFSET_BITS=64 -I/depot/package/gtk+_1.2.8/include
>       -I/depot/package/glib_1.2.8/lib/glib/include -I/depot/package/glib_1.2.8/include
>       -I/usr/openwin/include -DHAVE_AV_CONFIG_H -I.. -D_FILE_OFFSET_BITS=64
>       -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o jfdctfst.o jfdctfst.c
>       jfdctfst.c: In function `row_fdct':
>       jfdctfst.c:116: error: `int_fast16_t' undeclared (first use in this function)
[consecutive errors snipped]
 
>    We assumed that it might be due to the name collision between header files
>    with same name. The ideal solution would be to pass the path to those

Which would be inttypes. Actualy configure does some checking whether
int_fastXX_t exist and defines them itself if not.
see libavcodec/common.h. I guess something went wrong in this detection.

>    libraries to configure using syntax like
>       --with-libpng=<path-to-libpng>
>    Since, the configure script does not have this option right now, is there
>    any way to set the path? Any which libraries will we need in order to
>    compile the GUI interface?

You cannot set them separately, we have these options only for libs
which are commonly installed in non-standard paths. Otherwise we would
end up with thousands (yes, i mean this literaly) of this --with-libXXX
options. A better aproach is to find out why the inttypes detection
fails and fix it.

> 3. When we tried t access the UNIX manual page by type
>       man mplayer
>    we got the following error message:
> 
>       Reformatting page.  Please Wait...nroff: Out of temp file space;
>       line 4218, file /depot/man/man1/mplayer.1
> 
>     Any ideas what might go wrong?

Hmm.. i though manpages were formated with troff...
Maybe i'm wrong once again :)
I'd say that nroff had problems parsing and replacing the macros and
filled your ram (resp /tmp which are equivalent on a standard solaris
installation)

> 
> Mplayer is an impressive piece of work, and it would be lovely to have it
> available. Thanks in advance for your time.

Well.. actualy it should always compile on solaris, unfortunately
i seem to be the only one who cares about it and i didnt had to much
time (and also interest) in checking it.

BTW: if you store everything you compile in a separate directory, why
dont you use stow (from www.gnu.org) or SEPP (iirc sepp.ee.ethz.ch or
sepp.ethz.ch) ? Both provide a way to have the libs where programs
expect them.

HTH and sorry for the late answer.


				Attila Kinali