build problems with svn r22818

[sci-fi@…]

Hi,
I saw the changes being done over the last day or so, esp. to libdha. Sho'nuf we got some build problems now in several places. ;) I'll upload the logs etc. soon as bugzilla will let me. (I'm using bugzilla since gmane probably will filter-out these big attachments for the maillist.)

[sci-fi@…]

./configure console log

[sci-fi@…]

fresh svn update, no private alterations, no ./configure parms, no xFLAGS env-vars set, etc.

[sci-fi@…]

configure.log

[sci-fi@…]

copy of generated configure.log file during ./configure
(fresh svn update, no private alterations, no ./configure parms, no xFLAGS env-vars set, etc.)

[sci-fi@…]

config.h

[sci-fi@…]

copy of generated config.h file during ./configure
(fresh svn update, no private alterations, no ./configure parms, no xFLAGS env-vars set, etc.)

[sci-fi@…]

config.mak

[sci-fi@…]

copy of generated config.mak file during ./configure
(fresh svn update, no private alterations, no ./configure parms, no xFLAGS env-vars set, etc.)

[sci-fi@…]

make -w depend console log

[sci-fi@…]

console log buffer capture of "make -w depend" showing some of the build problems
(fresh svn update, no private alterations, no ./configure parms, no xFLAGS env-vars set, etc.)

[sci-fi@…]

The main problem is that make seems to lose how to find the Live555 headers etc. even tho they were properly detected during ./configure and tho the latest available (2007.02.20) are installed & compiled in a known standard location e.g. /usr/local/lib/live in this case.

Also the vidix/drivers section can't find the libdha headers, but vidix should not be building for OSX systems, it should be skipped, right?

Another problem is that someone added some compiler options that don't work with some flavours of gcc e.g. -mno-omit-leaf-frame-pointer in the loader section.

And the built-in libdvdcss section gripes about no DVD ioctls -- for OSX???? Of course not! Apple won't let us monkey around with low-level stuff like that. ;) I must manually do --disable-libdvdcss-internal _and_ --disable-dvdread-internal for things to use the external libs I have built separately. Shouldn't ./configure figure out this is broken for OSX and disable them automatically?

You'll also see that the glib/gtk+ stuff is detected because I have built the latest available stuff from Gnome except for the desktop subsystem itself (we use quartz-wm when starting up Apple's X11). A bunch of other requisites to get Pan working on OSX is also installed here now, and it all works fine. But mplayer's build system apparently gets mixed-up by itself, it doesn't seem to remember or use the pkg-config strings for gtk+-2.0 and gthread-2.0 plus X11's criteria (all of which are required for proper linking), so I must put these into LDFLAGS to clear this up. But with the current svn, the #includes for e.g. gtk/gtk.h & others are wrong, because we are using gtk+-2.0, and it should find the headers in /usr/local/include/gtk-2.0 etc.

There are probably other problems I haven't spotted yet, this was quite a big thing to gawk at all-of-a-sudden-like.

The logs attached to this bugreport were done with no alterations whatsoever. However, with a lot of hand-tweaking, but before this svn rev came out, I had been able to build mplayer r22768 this way:

#
export CFLAGS=" ${CFLAGS} -ffast-math -fomit-frame-pointer "
export CXXFLAGS="${CFLAGS}"
export CPPFLAGS="${CFLAGS}"
export LDFLAGS="${LDFLAGS} pkg-config --libs gtk+-2.0 gthread-2.0 "
#
./configure \
--with-sdl-config=/usr/local/bin/sdl-config \
--with-freetype-config=/usr/local/bin/freetype-config \
--with-dvdnav-config=/usr/local/bin/dvdnav-config \
--realcodecsdir=/usr/local/lib/mplayer \
--enable-dynamic-plugins \
--enable-largefiles \
--enable-menu \
--enable-altivec \
--enable-qtx \
--enable-macosx \
--enable-macosx-bundle \
--enable-macosx-finder-support \
--disable-faad-internal \
--disable-tremor-internal \
--enable-color-console \
--enable-gui \
--disable-debug \
--disable-dvdread-internal \
--disable-libdvdcss-internal \
--disable-crash-debug
#

With a patch to ./configure removing the automatic disallowance of building opengl under OSX, I can actually build & use almost all plain vo's including gl and gl2 as long as Apple's X11 is running and the DISPLAY env-var is properly set.

But as of today's svn, even my tweaks aren't enough to fix the problems introduced today -- from the last working build r22768 with my tweaks:

Byte order: big-endian
Optimizing for: 970 altivec
Languages:

Messages/GUI: en
Manual pages: en

Enabled optional drivers:

Input: ftp tv live555 cddb cdda dvdread dvdnav vcd network
Codecs: qtx x264 xvid libdv amr_wb amr_nb libavcodec real xanim faad2 faac musepack libmpeg2 libdts liba52 mp3lib libtheora speex libvorbis twolame libmad liblzo gif
Audio output: openal jack esd sdl mpegpes(file) macosx
Video output: md5sum sdl gif89a pnm jpeg png mpegpes(file) caca opengl xv x11 xover tga macosx quartz
Audio filters:

Disabled optional drivers:

Input: vstream pvr radio tv-v4l2 tv-v4l1 libdvdcss dvb smb
Codecs: win32 toolame
Audio output: sun alsa polyp arts oss ivtv dxr2 nas
Video output: xvidix winvidix cvidix bl zr zr2 ivtv dxr3 dxr2 vesa fbdev svga aa ggi xmga mga dga xvmc dfbmga directfb tdfx_vid s3fb tdfxfb 3dfx
Audio filters: ladspa

<<<<

And everything built quite cleanly. Yes I've been able to use all of the listed output modes, some work better than others of course but that's to be expected. What's more, I can actually run gmplayer and pick the skins I want to show there.

So some changes have been committed to ruin a lot of this as of today's svn.

I'm using GNU make-3.81 and other latest tools they have (even tho some don't apply to this project). Apple's gnumake (3.80) doesn't seem to help.

btw fwiw today's ffmpeg builds just fine.

Thanks for any help, and let me know if I can try anything (I'll stay tuned as long as the local free open hotspot stays working).

[diego@…]

(In reply to comment #6)

The main problem is that make seems to lose how to find the Live555 headers
etc. even tho they were properly detected during ./configure and tho the
latest available (2007.02.20) are installed & compiled in a known standard
location e.g. /usr/local/lib/live in this case.

The 'make depend' failure because of this should be irrelevant.

Also the vidix/drivers section can't find the libdha headers, but vidix should
not be building for OSX systems, it should be skipped, right?

It's just 'make depend' that unconditionally recurses into all directories.

Anyway, the libdha problem should be resolved.

And the built-in libdvdcss section gripes about no DVD ioctls -- for OSX????
Of course not! Apple won't let us monkey around with low-level stuff like
that. ;) I must manually do --disable-libdvdcss-internal _and_
--disable-dvdread-internal for things to use the external libs I have built
separately. Shouldn't ./configure figure out this is broken for OSX and
disable them automatically?

Nonsense. You've been "monkeying around" with configure flags and disabled internal libdvdcss. Thus DARWIN_DVD_IOCTL is not added to config.h and this error appears when 'make depend' descends into the libdvdcss subdirectory.

You'll also see that the glib/gtk+ stuff is detected because I have built the
latest available stuff from Gnome except for the desktop subsystem itself (we
use quartz-wm when starting up Apple's X11). A bunch of other requisites to
get Pan working on OSX is also installed here now, and it all works fine. But
mplayer's build system apparently gets mixed-up by itself, it doesn't seem to
remember or use the pkg-config strings for gtk+-2.0 and gthread-2.0 plus X11's
criteria (all of which are required for proper linking), so I must put these
into LDFLAGS to clear this up. But with the current svn, the #includes for
e.g. gtk/gtk.h & others are wrong, because we are using gtk+-2.0, and it should
find the headers in /usr/local/include/gtk-2.0 etc.

All irrelevant on OS X, where the GUI is not built.

The logs attached to this bugreport were done with no alterations whatsoever.
However, with a lot of hand-tweaking, but before this svn rev came out, I had
been able to build mplayer r22768 this way:

#
./configure \
--with-sdl-config=/usr/local/bin/sdl-config \
--with-freetype-config=/usr/local/bin/freetype-config \
--with-dvdnav-config=/usr/local/bin/dvdnav-config \

You really should just fix your path ..

--realcodecsdir=/usr/local/lib/mplayer \

Why not 'codecs'? The binary codecs are not used just by MPlayer ..

--enable-dynamic-plugins \

What for?

--enable-largefiles \
--enable-altivec \
--enable-macosx \

Should be unnecessary.

--enable-qtx \

Huh? This works differently on OS X.

--disable-debug \
--disable-crash-debug

Unnecessary.

#

With a patch to ./configure removing the automatic disallowance of building
opengl under OSX, I can actually build & use almost all plain vo's including
gl and gl2 as long as Apple's X11 is running and the DISPLAY env-var is
properly set.

It works for you? Please send that patch to mplayer-dev-eng.

[sci-fi@…]

(In reply to comment #7)

(In reply to comment #6)

The main problem is that make seems to lose how to find the Live555 headers
etc. even tho they were properly detected during ./configure and tho the
latest available (2007.02.20) are installed & compiled in a known standard
location e.g. /usr/local/lib/live in this case.

The 'make depend' failure because of this should be irrelevant.

The point is that this has changed and has stopped working properly with the recent changes.

The nightly svn snapshots do the same thing, as of mplayer-checkout-2007-03-25.

Also the vidix/drivers section can't find the libdha headers, but vidix should
not be building for OSX systems, it should be skipped, right?

It's just 'make depend' that unconditionally recurses into all directories.

Anyway, the libdha problem should be resolved.

I'll get another checkout asap... thank you for looking into this.

And the built-in libdvdcss section gripes about no DVD ioctls -- for OSX????
Of course not! Apple won't let us monkey around with low-level stuff like
that. ;) I must manually do --disable-libdvdcss-internal _and_
--disable-dvdread-internal for things to use the external libs I have built
separately. Shouldn't ./configure figure out this is broken for OSX and
disable them automatically?

Nonsense. You've been "monkeying around" with configure flags and disabled
internal libdvdcss. Thus DARWIN_DVD_IOCTL is not added to config.h and this
error appears when 'make depend' descends into the libdvdcss subdirectory.

Diego, please re-read the attachment comments I posted here:
"fresh svn update, no private alterations, no ./configure parms, no xFLAGS
env-vars set, etc."
And I mentioned already that the nightly svn snapshot acted the same way.
ABSOLUTELY NO MONKEYING AROUND as you put it.
I don't know how to make it any plainer. ;)

You'll also see that the glib/gtk+ stuff is detected because I have built the
latest available stuff from Gnome except for the desktop subsystem itself (we
use quartz-wm when starting up Apple's X11). A bunch of other requisites to
get Pan working on OSX is also installed here now, and it all works fine. But
mplayer's build system apparently gets mixed-up by itself, it doesn't seem to
remember or use the pkg-config strings for gtk+-2.0 and gthread-2.0 plus X11's
criteria (all of which are required for proper linking), so I must put these
into LDFLAGS to clear this up. But with the current svn, the #includes for
e.g. gtk/gtk.h & others are wrong, because we are using gtk+-2.0, and it should
find the headers in /usr/local/include/gtk-2.0 etc.

All irrelevant on OS X, where the GUI is not built.

Diego, I should have known better than to mix-up issues here, because it seems we never can keep things straight. ;) With my _alterations_ (of which I did not post logs here), yes the GUI _does_ get built and works quite nicely with Apple's X11 and all the paraphernalia I had to build for Pan -- I've seen several nice as well as ugly skins. ;)

But something's wrong with the UNALTERED logs I did post up here. Why is make depend trying to find headers that do not exist in several areas including gtk?!? This did not happen back during my last good svn checkout of r22768 as I mentioned.

The logs attached to this bugreport were done with no alterations whatsoever.
However, with a lot of hand-tweaking, but before this svn rev came out, I had
been able to build mplayer r22768 this way:

#
./configure \
--with-sdl-config=/usr/local/bin/sdl-config \
--with-freetype-config=/usr/local/bin/freetype-config \
--with-dvdnav-config=/usr/local/bin/dvdnav-config \

You really should just fix your path ..

Since Apple & X11 insist on installing their back-level versions of SDL, freetype, fontconfig, etc. into /usr/X11R6, I must be sure to tell mplayer to use my latest builds in /usr/local. I threw in the explicit path for dvdnav-config for good measure. ;)

--realcodecsdir=/usr/local/lib/mplayer \

Why not 'codecs'? The binary codecs are not used just by MPlayer ..

All I have here are the real codecs (and sometimes will fetch their latest nightlies here, too). The win32 codec pkgs are worthless on a PPC box (abundantly clear in my logs ;) ). At any rate the MPlayer FAQ for real codecs on OSX IIRC say to place them here, and judging by the directory date/time stamps I've had them there since 2004. ;)

--enable-dynamic-plugins \

What for?

We're building other projects that use/need ffmpeg/mplayer and need this function AFAICR.

--enable-largefiles \
--enable-altivec \
--enable-macosx \

Should be unnecessary.

I'm also trying to figure out a couple Finder problems in this area, so I explicitly enable or disable them here.

--enable-qtx \

Huh? This works differently on OS X.

I'm hoping to get non-Apple libquicktime project working as well, I'm closely following their maillist also.

--disable-debug \
--disable-crash-debug

Unnecessary.

~sigh~
They are there so _I_ can enable them if needed.
The FAQ for bugreports say to report anything & everything, so I am quoting my console logs as verbatim as I can. ;)

#

With a patch to ./configure removing the automatic disallowance of building
opengl under OSX, I can actually build & use almost all plain vo's including
gl and gl2 as long as Apple's X11 is running and the DISPLAY env-var is
properly set.

It works for you? Please send that patch to mplayer-dev-eng.

The patch is just to scrub the "&& test "$_macosx" != yes" on line 4129 of configure as found in the mplayer-checkout-2007-03-25 tarball, then it'll be detected & build, and work as long as X11 is running & DISPLAY is set properly. (This isn't shown in the posted logs for this bugreport because I did not want to have any alterations at all to prove where these make bugs are currently. ;) )

Again let's not go into the tweaks I've done, I only mention them to show how much work it'll be to get nearly everything working on OSX, but also to say my tweaks didn't help the current svn situation at all. All this bugreport should be for is to get the recent changes working as before: we need to fix make depend and make all (which I did not post because make depend failed so bad, let's do one thing at a time "KISS").

I used to understand all of the configure scripts & Makefiles etc., but way too much has been changing, and seem to be more "thick" or "layered" than it really needs to be. So I would appreciate some help to find why these are happening with current svn, when r22768 was the last good one I've been able to build here in all regards.

Thank you & anyone else for any help. :)

[diego@…]

(In reply to comment #8)

(In reply to comment #7)

(In reply to comment #6)

The 'make depend' failure because of this should be irrelevant.

The point is that this has changed and has stopped working properly with the
recent changes.

Yes, but the error is of purely cosmetical nature ..

And the built-in libdvdcss section gripes about no DVD ioctls -- for OSX????
Of course not! Apple won't let us monkey around with low-level stuff like
that. ;) I must manually do --disable-libdvdcss-internal _and_
--disable-dvdread-internal for things to use the external libs I have built
separately. Shouldn't ./configure figure out this is broken for OSX and
disable them automatically?

Nonsense. You've been "monkeying around" with configure flags and disabled
internal libdvdcss. Thus DARWIN_DVD_IOCTL is not added to config.h and this
error appears when 'make depend' descends into the libdvdcss subdirectory.

Diego, please re-read the attachment comments I posted here:
"fresh svn update, no private alterations, no ./configure parms, no xFLAGS
env-vars set, etc."

The internal libdvdcss copy depends on internal dvdread. I don't see how

if test "$_libdvdcss_internal" = auto ; then

_libdvdcss_internal=no
test "$_dvdread_internal" = yes && _libdvdcss_internal=yes

fi

can end of with libdvdcss_internal being no unless you set it explicitly ...

But something's wrong with the UNALTERED logs I did post up here. Why is make
depend trying to find headers that do not exist in several areas including
gtk?!? This did not happen back during my last good svn checkout of r22768 as
I mentioned.

I repeat: make depend was changed to recurse into all subdirectories.

--realcodecsdir=/usr/local/lib/mplayer \

Why not 'codecs'? The binary codecs are not used just by MPlayer ..

All I have here are the real codecs (and sometimes will fetch their latest
nightlies here, too). The win32 codec pkgs are worthless on a PPC box
(abundantly clear in my logs ;) ).

The files can still be used by other programs, not only MPlayer..

BTW, I happen to be the one who created the Linux PPC codecs package :)

At any rate the MPlayer FAQ for real
codecs on OSX IIRC say to place them here, and judging by the directory
date/time stamps I've had them there since 2004. ;)

That's not a FAQ that I know of.

--enable-dynamic-plugins \

What for?

We're building other projects that use/need ffmpeg/mplayer and need this
function AFAICR.

What projects would that be? I've never heard of dynamic plugins working correctly and it is scheduled for removal.

we need to fix make
depend and make all (which I did not post because make depend failed so bad,
let's do one thing at a time "KISS").

Again, make depend should be working fine, the error output is of a purely cosmetical nature.

I used to understand all of the configure scripts & Makefiles etc., but way
too much has been changing, and seem to be more "thick" or "layered" than it
really needs to be.

Huh? I massively cleaned it up, about halving the linecount in the process. I'm open for suggestions, but I believe you just have to reread the relevant parts.

[diego@…]

(In reply to comment #6)

I must manually do --disable-libdvdcss-internal _and_
--disable-dvdread-internal for things to use the external libs I have built
separately. Shouldn't ./configure figure out this is broken for OSX and
disable them automatically?

Note: They are not broken on OS X.

[diego@…]

(In reply to comment #9)

The internal libdvdcss copy depends on internal dvdread. I don't see how

if test "$_libdvdcss_internal" = auto ; then

_libdvdcss_internal=no
test "$_dvdread_internal" = yes && _libdvdcss_internal=yes

fi

can end of with libdvdcss_internal being no unless you set it explicitly ...

Ummm, I should look more closely. The internal libdvdread is disabled by libdvdnav. What do you want libdvdnav for anyway? It's not like DVD menus work correctly ..

[sci-fi@…]

Hi,

Have been *>extremely<* busy on other projects, but let's stay on one topic here. ;)

I can't see how the make depend problems are "cosmetic" -- it is outright showing which files it cannot find. That is _not_ "cosmetic"! Can't find the headers, can't get any reliable dependencies -- right?

Okay I have stumbled on a patch to consider (and consider only) for letting make depend find the live555 headers (look at my logs again: these cannot be found either). I know this patch ain't right, I'm only providing a clue in this one area only to fix make depend w/r/t live555. Just for showing what might be needed to fix this one area -- okaY?!? ;)

I'll attach a file named mplayer_mpcommon-mak_fixmakedepend.patch to this report as a point for discussion on letting make depend find the live555 headers. It might fix other files it's missing, too, but I was mainly concerned about live555 here.

I have a couple other possible patches to consider, too, for other anomalies in the make depend logs I posted here. But let's do one thing at a time here, please. ;)

[sci-fi@…]

possible fix for letting make depend find live555 headers

[sci-fi@…]

See my comment #12 for explanation.

[diego@…]

I have fixed the failure of make depend when live555 is enabled. If other issues remain, please open another bug report, this one is becoming unwieldy.