Fink

I got ahold of Justin and got the goahead to merge an updated (1.1.12)
version of your package + libcaca 0.99 into the pangocairo branch, which
we're hoping to get released very soon. I tested on 10.5/intel, 10.5/ppc,
and 10.4/intel and all seems to be going well. Thanks much for your hard
work!

clean build: it turned out that the differences between clean and
production were not caused by the new libxine package but rather by a) an
outdated freetype or fontconfig package (.. my fault), b) an ImageMagick
which was also linked against some system libs. by rebuilding those
packages, and re-doing both builds, I did end up with an identical output
of Alex' fink-check-deps script.


libsndfile1: during the clean build, libsndfile1 did not compile. Its
patch affect configure.ac which triggers the autotools which fail on my
configuration and no explicit versions of the autotools are selected in the
package so I've changed the patch to patch configure directly instead of
the configure.ac. can someone please approve this revision at
https://sourceforge.net/tracker/index.php?func=detail&aid=1946161&group_id=17203&atid=414256


patches: most previous patches have been accepted upstream in the current
1.1.12 version. we still have a fix for X detection on pre-10.5 systems,
the "usual" OpenGL LDFLAGS fix, and I've disabled a xine deinterlacer
((Toms Motion Compensated Deinterlace aka tomsmocomp..). The de-interlacer
cannot be compiled on XCode 3.0 on x86-32. This de-interlaces results in a
no-op (it does not deinterlace) on non-x86 systems anyway.


upgrade path: to me, the simplest solution would be a libxine2 without
paying to much attention to the 4 packages which depend on libxine1 and
notify those maintainers that there's an updated libxine available. An
update to the new xine-lib should be most interesting to the videocut
package which is sports a new maintstream version btw. amarok-engine-xine
works with the new xine-lib, but there xine is only used for audio playback
and there are not that many changes on that front (I guess). kmplayer
worked with new xine-lib, gxine didn't want to show a video to me. There is
the general problem of xine-frontends which come from the X11 community
that they don't know how to use the mac os x video output and just assumes
Xv with video overlay is working well, which is not the case on mac, as far
as I know.
I was thinking on a) packaging xine-ui to have at least a recent front-end
even if its using X11 output and maybe to try to port it to use the mac os
x video output which would lead to an X11-ish looking but powerful
movieplayer.


other issues, not relevant yet, but maybe later. libxine1 is build against
an external ffmpeg. this ffmpeg is from 2007-12 but build without mmx
support which probably happended due to this annoying restriction in XCode
3.0 of not building a shared library which contains absolute addressing on
x86. I do see the point that absolute addressing shouldn't be used in a
shared library, however, other platforms and other XCode versions don't
mind and nobody will be be able to convince the ffmpeg guys to fix this
(see my post to fink-devel on this). the asm code can be slightly altered
as it is done by the Perian project to compile the mmx version with PIC
addressing with XCode 3.0. however, their fix is only done for "half" of
ffmpeg so it cannot be used to compile a complete ffmpeg or libxine with
mmx support. I might try to extend the fix to the whole ffmpeg one day but
I guess I'll do other stuff first. e.g. libxine does not play audio cds
(yet), although an experimental branch with this feature already exists.


current .info/.patch files: see my post to fink-devel-list as I'm neither
submitter for this package nor have fink developer status. e.g.
http://www.nabble.com/Re%3A-libxine1-again---version-1.1.11-p16815820.html

Using Matthias' .info and .patch files from fink-devel, the build seemed
to have worked OK for me on a clean 10.5/powerPC system. (I modified it
for the old caca)

re-assigning to myself in absence of any reaction of the
previous assignee and maintainer since weeks, despite
several additional requests by private e-mail

JF

hi JMF.

while doing a clean build, I stumbled upon libsndfile1 which did not build
on my clean system. I've fixed this at
http://sourceforge.net/tracker/index.php?func=detail&aid=1946161&group_id=17203&atid=414256
maybe you can approve this quickly.

libxine1 builds in the clean environment and I found some missing
builddeps. But I still have some differences to my "productive" system.

production uses:
-I/usr/X11/include
/usr/X11/lib/libfreetype.6.dylib
/usr/lib/libexpat.1.dylib
/usr/lib/libresolv.9.dylib

clean uses:
-I/sw/lib/fontconfig2/include
expat1-shlibs: /sw/lib/libexpat.1.dylib

although expat1 is in builddeps the productive system did pick up the
system one and not fink's.
also different includes are used but the configure output is identical up
to this point.
will have to look at the config.log of both.

gxine does build but not run with the new xine. have to test with the old
one but I'm on some kind of holiday and only have the macbook with me, not
the powerbook.
videocut builds and works.

xine-lib-1.1.12 is out now which contains these patches:
- list open gl
- fix for quicktime mp4
- mac os x video output

matthias

concerning the "2008-04-08 00:57" patch msg
the fix was accepted without comment at
http://hg.debian.org/hg/xine-lib/xine-lib?cmd=changeset;node=840dd71d0c43;style=gitweb

Hi !

Updated the patchscript with your ref; also removed the patch-file,
that was maiming the pkg, and removed all "disables" from the
configure parameters.

Didn't yet patch for your "2008-04-08 00:57" msg here
(had forgotten it), so please add a corresponding line (+ comment
linking to upstream discussion) in the patchscript
(at least if you have reactions from upstream approving your patch,
or if you feel completely confident about it).

So the pkg probably again needs testing on as many machines
and systems as all of you can put your hands on...

Also, Mathias, if I can ask you for a big favour, it would be to go for
both pkgs through the procedure described in
http://wiki.finkproject.org/index.php/Fink:CleanBuild..

As to Justin, I finally got from him a week ago a reply to a private
e-mail
asking him to look at this thread; but no news since..
So in absence of further reaction from his part, we'll have to proceed;
in that case, I was thinking of putting you as maintainer of the
2 updates, if you agree.

The update of caca should be no problem, the only other dep
being gst-plugins-good-0.10, this should be just revved-up
(builds w/o problem) _ and I already had an e-mail exchange
with the maintainer concerning this..

For libxine1, the situation is a bit more complicated; there are
4 depending pkgs: gxine, videocut, amarok-engine-xine, and
kmplayer.
One would have to check source- and binary-compatibility between
the new libxine1 and the old one...
I.e., in practice, (a) whether those pkgs, built with the old libxine,
are still functional with the new one (install_names are the same,
so one should a priori expect this...)
and (2), whether those same packages still build correctly with the
new libxine1 _ and if yes, whether the deb is "identical".

The upgrade strategy has to depend on those answers ...
Matthias _ can I ask you for another big favour ? It is to look
at those issues....
In particular, I can't look at them, because I can't build an "old
libxine1" ...

Thanks a lot in advance !

JF


File Added: libxine1.info

hi jean-francois.

sorry for the insult of supporting java to you... :)

xine-lib mercurial shows an increased version number, so maybe 1.1.12 is
around the corner.

if not, we need at least another fix from there which fixes a bug in
quicktime playback.
This time, I was only looking at the repository to see what broke
quicktime playback (h264/mp4 from German news magazine "Tagesschau")
between 1.1.9 and 1.1.11.1 to stumble over it.

http://hg.debian.org/hg/xine-lib/xine-lib?cmd=changeset;node=d8e1305c1382;style=gitweb

what's with the libcaca package. are were done with it?

matthias

"If you like this patch, you probably will also like
libxine-java.sourceforge.net ... :)" _ I really don't
like anything that has java in its its name, because
I really don't understand this stuff...
cf e.g. recent exchange on fink-devel....)

Cheers,

JF

explanation for the patch below:

For YUY2, twice the amount of data was copied into the OpenGL
texture_buffer leading to a segfault. The crash happened with visualizers
such as GOOM and oscope but not for normal video.

---

"If you like this patch, you probably will also like
libxine-java.sourceforge.net ... :)"

you're wonderful!

A hint (link) to the explanation ??

JF

just found, fixed & reported upstream a bug in xine-lib 1.1.11.1 which is
fixed by this:

--- a/src/video_out/video_out_macosx.m Mon Apr 07 17:59:25 2008 +0100
+++ b/src/video_out/video_out_macosx.m Mon Apr 07 23:46:20 2008 +0200
@@ -207,7 +207,7 @@ static void macosx_display_frame(vo_driv
break;
case XINE_IMGFMT_YUY2:
xine_fast_memcpy (texture_buffer, vo_frame->base[0],
- vo_frame->pitches[0] * vo_frame->height * 2);
+ vo_frame->pitches[0] * vo_frame->height);
[driver->view updateTexture];
break;
default:

with the fix for not using gcc-3.3 it compiles here on 10.5, PPC and the
cacafire demos shows in a cocoa window.

as for the shorter than x contest regarding:
perl -pi -e 's, \${MACOSX_SDK_[A-Z]*},,; s/-syslibroot,\${MACOSX_SDK},//;
s, *\${ARCH} *,,; s,-\${GCC_VERSION},,' configure

what about..
perl -ne 'print unless 23252 .. 23278' configure

which is still a bit verbose due to the perl syntax. let's try with sed..
sed -i -e '23252,23278d' configure

true.. it's only valid for this configure script, but isn't this normal
for patch file/scripts?
anyway, I think I've won this round. :)


concerning the man3caca patch. in the latest caca.info from this tracker,
the first line of the patchscript reads:
perl -pi -e 's,man/man3,man/man3caca,g' doc/Makefile.in
but a grep "man/man3" does match anything.

other than that, I guess the caca package is good enough.

btw. the <cocoa/cocoa.h> test can be fixed by testing for an objective c
compiler in the configure.ac in a few lines. but then, configure needs to
be re-generated which could be tricky sometimes.

let's go back to libxine1 and see, if we're done with that.

Oh _ seeing now your trouble with gcc (this doesn't occur
on intel, had to go and read configure to figure it out) ;
please replace the last line in the patchscript by :

perl -pi -e 's, \${MACOSX_SDK_[A-Z]*},,; s/-syslibroot,\${MACOSX_SDK},//;
s, *\${ARCH} *,,; s,-\${GCC_VERSION},,' configure

JF

PS : except if you find a shorter line doing the same .. -)

File Added: caca.info

I see no man/man3 replacement anymore in my info file
(though I remember having seen there a strange thing like
man3caca ..)

This libcucul-dev story is very bad; moving it to libcaca-dev
(don't want to complicate things now with 2 separate pkgs).

Updating files thus to make sure we're talking about the same thing ..
(too bad there is no "cvs diff" facility..)

JF
File Added: libxine1.info

ok , added your perl line for configure's output..

Don't understand your comment :
"cocoa output driver of libcaca. the configure test fails testing..." :
I have only :
checking Cocoa/Cocoa.h usability... no
checking Cocoa/Cocoa.h presence... yes
configure: WARNING: Cocoa/Cocoa.h: present but cannot be compiled
configure: WARNING: Cocoa/Cocoa.h: check for missing prerequisite
headers?
configure: WARNING: Cocoa/Cocoa.h: see the Autoconf documentation
configure: WARNING: Cocoa/Cocoa.h: section "Present But Cannot Be
Compiled"
configure: WARNING: Cocoa/Cocoa.h: proceeding with the preprocessor's
result
configure: WARNING: Cocoa/Cocoa.h: in the future, the compiler will take
precedence
checking for Cocoa/Cocoa.h... yes

This happens in so many configure scripts (for other headers) that I'm no
longer
paying attention to it _ as long as the conclusion is correct !
Sure it is better if you can send a fix upstream...
But do you have anything worse ?
(with the info file below)

Adding the LDFLAGS and taking care of the noop; then will check
systematically
the dep issues (but there I'm in favour of (a) + (b), since there are so
few deps,
and since the previous version installed no shlibs _ thus no need to
preserve
anything)

JF

oh ! the fix to configure i just for output, right ?
can add it nevertheless .

caca: "the use of gcc-3.3 has to go away"
there is no such use; did you run the info file below ?

Looking at the rest now..

Cheers,

JF

here's the fix to make xine-lib's configure list opengl if detected:

perl -pi -e 's/x\$\"ac_have/\"x\$ac_have/g' configure

or as a proper patch file:

--- xine-lib-1.1.11.1/configure 2008-04-03 23:31:48.000000000 +0200
+++ xine-lib-1.1.11.1-new/configure.new 2008-04-05 20:56:47.000000000
+0200
@@ -54003,7 +54003,7 @@
echo "$ac_have_glu"

if test "x$ac_have_opengl" = "xyes" -a "x$ac_have_glut" = "xyes" -o \
- x$"ac_have_opengl" = "xyes" -a "x$ac_have_glu" = "xyes"; then
+ "x$ac_have_opengl" = "xyes" -a "x$ac_have_glu" = "xyes"; then
echo " - OpenGL"
fi
if test "x$ac_have_sunfb" = "xyes"; then

as a positve feedback. your patches together with my cocoa / ppc / 10.5
fixed produce a working cacafire running in a native cocoa window! :)

Hi jean-francois. I've just found your updated caca.info attached to this
tracker item. you fixed other stuff than me...


gst-plugins-good-0.10 depends on libcaca-dev. we have to either a) make
sure it still compiles, b) see if it can be updated, c) add a libcaca1-dev.
I guess c) is the simplest solution. also.. (read on)
libcaca now provides the lower-layer stuff as libcucul. Ubuntu provides
both packages separately. Maybe we could/should do the same. I was
wondering about this, when I figured out that libcaca would install into
/%p/share/doc/libcucul-dev ...


to compile beta12 or 13b on PPC, the use of gcc-3.3 has to go away (on
10.5 there is no gcc-3.3 anymore). to fix configure for me, I just removed
the complete mac os x specific part in the configure script (only left the
-Framework Cocoa flag). I can send you the patchfile per email if you want
to see the removed lines.

cocoa output driver of libcaca. the configure test fails testing
Cocoa/Cocoa.h for the simple reason that it does not invoke the Objective C
compiler but uses plain old gcc which just cannot cope with
<cocoa/cocoa.h>. The simplest fix is to remove the cocoa test from
configure and just set it to true. we're on apple anyway. The actual
compile of the cocoa driver goes well as gcc automatically invokes
Objective-C when it encounters a .m file.

To compile on 10.5 the same SetLDFlags tag is needed as for libxine.

The first man/man3 replacement in you .info is a no-op as there is no such
string.

cheers. I'm going to compile xine-ui to see if aaxine and cacaxine will
work with this.

argl. I've also build a new caca package, using beta13.
At the first try, it did not build the cocoa output driver (bugs in the
source code). Then, I've found a patch for it on the libcaca mailing list.
strange thing, I applied the patch once to a fresh source tree. but now, it
compiles with the fink package without this patch. Besiedes the configure
stuff (I decided on just removing all the mac os specific code besides
keeping the cocoa framework linker flag) I only had to commend a single
typedef. should we compare .info files? did you commit yours to fink cvs?


Ah. I've got xv.pc & xcb-vx.pc in /usr/X11/lib/pkgconfig/
So, I guess looking for xv.so on mac should be considered a bug. Could you
make a cross-platform fix to the configure.ac to forward to xine-devel?

updated caca with version beta12 _ the configure stuff
is easily patched to give a norma build; but version 13b
has bad bugs in the code.

concerning the patch _ configure first looks with pkgconfig
for a file 'xv.pc'; maybe there is such a .pc file in 10.5's X11,
but there is none in xorg's, so then it looks first for an .so
file, then for an .a file ..

JF

File Added: libxine1.info

hi again.

did you delete the right file? :)
the latest ("rev by jmf") uses libxine-1.1.11 and does not have the
corrected LDFLAGS setting. can you upload your updated file again?

hi jean-francois.

we're getting closer.

CACA: xine-lib 1.1.11.1 requires CACA >= 0.99. CACA 0.99beta13 (latest
"official" snapshot from 12/2007) has strange stuff in the configure.ac. I
got impatient, but surely CACA will compile on 10.4 & 10.5. funny, they had
completely different stuff for PPC and INTEL.

The patchfile is needed for XCode 3.0 on 32-bit Intel. We could apply the
patch only if XCode 3.0 is used. It disables one or two de-interlacers. But
the current patchfile is rather short, only 40 lines.

OpenGL enumeration. It is not relevant for this package, as the OpenGL
video out plugin IS build. It is just not listed. Nevertheless, I can add
this trivial fix to the PatchScript.

For the PKG_CONFIG: If you verified that it is needed, fine with me.

The so->dylib patch: strange. so this patch is needed at your machine
(10.4 you said). but it is not needed on my 3 machines (G4, G5, Core Duo)
on 10.5 strange. can you send me a config.log with and without the
patchscript please to compare with mine? If it is needed at your machine,
it has to be fixed upstream, don't you think so?

---

I'll test the latest .info.
Btw. I did send Justin at least two emails in the last 4 months without an
answer...

attaching a rev to 1.1.11.1; checked also (via nm) that
/sw/lib/xine/plugins/1.20/xineplug_vo_out_macosx.so
is safe; it uses no GL symbols at all ..
(and revised slightly he deps.)

Further comments ?

And please test !

Justin : please test too, and reply to the thread ..

Jean-Francois

Sorry for the late reply ..

1) Re: OpenGL _ see no such driver.
patching the tests for gl.h in configure is nevertheless probably
helpful;
I see with otool that while libxineMacOSXVideo links purely with the
framework (as expected),
/sw/lib/xine/plugins/1.20/xineplug_vo_out_opengl.so:
/usr/X11R6/lib/libGL.1.dylib (compatibility version 1.2.0, current
version 1.2.0)
/usr/X11R6/lib/libGLU.1.dylib (compatibility version 1.3.0,
current version 1.3.0)
(or is this the opengl plugin you asked about ?)
and the following links against both _ this seems dubious, and has to be
checked carefully:
/sw/lib/xine/plugins/1.20/xineplug_vo_out_macosx.so:
/usr/X11R6/lib/libGL.1.dylib (compatibility version 1.2.0, current
version 1.2.0)
/usr/X11R6/lib/libGLU.1.dylib (compatibility version 1.3.0,
current version 1.3.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
(compatibility version 1.0.0, current version 1.0.0)

2) "OpenGL: there's a bug in the configure script which does not list
OpenGL
at the end of the configuration although it is properly detected. As it
is
not relevant for the fink package, I've just send the fix to xine-devel."

Why should it not be relevant ? Let us fix the bug in the patchscript ..

3) the PKG_CONFIG path is needed to link correctly (ie, against the
freetype etc pkgs
listed in the dependencies).

4) Concerning the patchscript :
without it you get:
checking for XV... checking for libXv.so... libXv.so not found in
/usr/X11R6/lib
checking for libXv.a... found libXv.a in /usr/X11R6/lib
and you will link with the archive ..

"if this would need to be patched then the
autotools maintainers would do a bad job" : no _ is hardcoded already in
configure.ac,
nothing to do with autotools..
Or that an incorrect detection has no influence on the build ?
I strongly doubt both ..

Do you claim that the patchfile is also superfluous ? This would be great
_ if at least some
items there could be discarded..

5) For CACA, "looks like they
have some strange Mac OS X stuff in configure" : "they" = caca-0.99 ?

JF

two more comments:

To compile libxine1 with all X11-based video out plugins and the OpenGL
video output, only the "export CPATH=%p/include:/usr/X11R6/include" was
required. No PatchScript (if this would need to be patched then the
autotools maintainers would do a bad job), and no PKG_CONFIG_PATH changes.

xine-lib 1.1.11.1 was released due to some security fix. we should go for
that one.

OpenGL: there's a bug in the configure script which does not list OpenGL
at the end of the configuration although it is properly detected. As it is
not relevant for the fink package, I've just send the fix to xine-devel.

the "famous bug": the fix from fink's own wiki page is this (and compiling
works on the problematic 10.5 XCode 3.0 machine)
SetLDFlags:
-Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.fr
amework/Versions/A/Libraries/libGL.dylib

CACA: xine requires caca 0.99. we (and macports) have 0.9. looks like they
have some strange Mac OS X stuff in configure. e.g. for PPC they want to
use gcc-3.3 and the 10.3 SDK... :(

Dependencies: I have about 5 I which I think should not be there. Most
important: xine-lib (nor any of its dependencies) does need/use qt3!

hi Jean-Francois
do you get "- OpenGL" as a video driver plugin?
I don't get them with or without your X, GL PatchScript

I've added the missing <a52dev/a52_internal.h> to a new revision of the
liba52dec package.
https://sourceforge.net/tracker/index.php?func=detail&aid=1933080&group_id=17203&atid=414256
This should allow libxine1 to build against it yet. (maybe someone can
approve & commit this quickly).

JFM: sorry, I thought one could provide ANY env variable with the SetENV
feature, but I was wrong. So, the CompileScript can stay.

updating the info file accordingly..

JF
File Added: libxine1.info

Forgot to add to point (1) :
This does not imply that one could dispense with the CompileScript:
AFAIK, neither CPATH nor PKG_CONFIG_PATH can be set by fink,
and they ARE needed for a correct build
(the CPATH _ contrary to what I said earlier in this thread, is (chiefly)
for the tests for GL/gl.h and GL/glu.h in configure to succeed _ and
the PKG_CONFIG_PATH is obvious)

JF

1) For "the HAVE_DARWIN_CDROM fix", you're completely right :
I checked that none of the headers directly or indirecty included
(even those of libcdio) tested for it.

2) for arts : thanks again ! I see indeed that arts was not among
my otool_deps, as it should have been.

3) concerning a52dec-dev as a bdep (and the corresponding shlibs
as dep) : I am positive that a52dec-shlibs appears here as a dependency
according to otool; this means one of the binaries has a lib _ say
libfoo.x.y.z.dylib _
in that pkg among its LOAD_COMMANDS, and will fail if that lib is not
found.
[Even if in fact no symbols are used from that library.. It probably came
on the link through an .la file of some dependent pkg..]
Now, since to get in the LOAD_COMMANDS, it has to appear in the link
command,
it (almost certainly) appears there as "-lfoo", and that is why
libfoo.dylib
(which is in the -dev pkg) has to be there at compile-time, else that link
will fail..

So those deps and bdeps are (almost) certainly correct.
I had noticed _ and regret as you _ that the "--with-external-a52dec" was
unsuccesfull _ but it doesn't do harm either, so better keep it as
documentation
for what is desired ...
(Maybe you could update it (it seems abandoned since long), and make it
install
the required internal headers)

4) for ffmpeg-dev: great !
hadn't yet gone through the chore of rebuilding adding (after the
configure phase)
"-H" to the CPPFLAGS, to grep from the log all indirectly included headers
and what
pkgs they came from..

5) yes, I'm sure; configure looks for the hard-coded name "libXv.so" _
and obviously
doesn't find it...
No matter where built, you'll rather have a "libXv.dylib".

Best, and thanks a lot !

JF

I've got some more comments:


Don't need the HAVE_DARWIN_CDROM fix -- the flag is only needed by libcdio
which is used as an external lib
Now, CompileScript can go away and the env variables can be set directly
by fink.

--with-arts (+ --disable-artstest) has to be given to enable arts support

the external ac52-dec-dev is not accepted by configure
(ac52dec/ac52_internal.h is missing) and the internal lib is used anyway.
the dependency can be dropped. (or the configure

ffmpeg-dev is required as BuildDependency -- otherwise, <ffmpeg/avutil.h>
is not accepted (as indirect headers are missing).

Jean-Francois: are you sure about the necessity of the PatchScript? all
X11-based packages are build here (10.5, XCode 3.1 beta 1)

I'll see after the "famous bug" later at home on a MacBook Pro (10.5,
stock XCode 3.0)

sure _ avahi comes from some experimental tree, and its absence should not
affect the buuild
(indirect dep).

As to the "most famous" bug _ can't help you there _ have no 10.5 system
to do the build,
or even to look at the man pages .. But it is classical, with known
solution..
If your SetLDFLAGS gives trouble, look in the config.log for its cause,
and fix then configure ..

(Does the trouble occur when checking for the compiler's default output
name ? )
But the exact error in config.log is important : both the specific cc or
gcc command,
and the compiler's error message..

JF

Can't resolve dependency "libavahi1-dev" for package
"libxine1-1.1.11-1031" (no matching packages/versions found)
So I took out libavahi1-dev as dependency.

Then comes up the most famous bug:

gcc ${wl}-undefined ${wl}dynamic_lookup -o .libs/xineplug_vo_out_macosx.so
-bundle .libs/xineplug_vo_out_macosx_la-video_out_macosx.o -L/sw/lib
../../src/xine-engine/.libs/libxine.dylib /sw/lib/libintl.dylib
/sw/lib/libiconv.dylib -L/sw/lib/freetype219/lib
/sw/lib/freetype219/lib/libfreetype.dylib -L/usr/X11/lib
/usr/X11/lib/libfontconfig.dylib /usr/lib/libiconv.dylib
/usr/X11/lib/libfreetype.dylib /usr/lib/libz.dylib /usr/lib/libexpat.dylib
/usr/lib/libresolv.dylib /usr/X11/lib/libX11.6.2.0.dylib
/usr/X11/lib/libXau.6.0.0.dylib /usr/X11/lib/libXdmcp.6.0.0.dylib
/usr/X11/lib/libXext.6.4.0.dylib /usr/X11/lib/libXinerama.1.0.0.dylib
-Wl,-framework -Wl,Cocoa -framework Cocoa -framework OpenGL
ld: cycle in dylib re-exports with /usr/X11/lib/libGL.dylib
collect2: ld returned 1 exit status

Even with my copy/past-line SetLDFLAGS enabled it doesn't work, in fact,
it doesn't even ./configure:

checking for C compiler default output file name...
configure: error: C compiler cannot create executables

What is the correct LDFLAGS-line? In fact, if I try it without fink, that
is, in a local directory only, the LDFLAGS-line does help the
linker-problem...

Assigning to the maintainer.
And up to him decide whether he wants
to keep maintainership or leave it to you.

JF

and pls correct the typo "libx264-dev0"
in the info file to "libx264-dev" before
trying to run it ..

JF

sorry _ forgot : also updated deps to current pkgs
(like pth -> pth2, libtool14 -> libtool2, imagemagick -> imagemagick1,
and removing refs to obsolete pkgs like gnome-vfs2 | gnome-vfs2-ssl )

JF

Hi Linus,
I tried your pkg, being tired to have a non-buildable libxine -)
It built OK (this is on 10.4 CoreDuo).
However I did a number of changes, of the following categories :
(now validates and builds correctly even with fink -m)

1) shlibs policy conformance (libxineMacOSXVideo was not in
the shlibs splitoff, and the Shliibs field was incorrect)

There remains still to make sure that all *.a files remain in the main
pkg.

2) ConfigureParams : disabled a bit less, enabled a bit more, and
especially used external libs whenever possible _ useless to duplicate
code ..

3) A couple of configure tests went wrong, fixed mainly by the
patchscript
(tests for libXv) and by the export PKG_CONFIG_PATH in the compilescript
(tests for GL/gl.h etc..)

4) started checking deps : added as deps of the shlibs anything that was
a
dependency according to otool, and similarly the corresponding -dev pkgs
were added if necessary to the builddepends.

5) cosmetic changes (e.g., readability of long lines..)

There remains several suspicious things; a.o.,
a) you should look carefully at the
configure output for any suspicious signs (eg., CACA),
and for indications of other(build)deps)
b) check carefully the patchfile whether any change has not become
superfluous, or improvable ..
c) at that stage, and when everything runs OK (didn't check
this aspect at all), one could have a second look at he dependencies
(for pruning legacy stuff that has become unused..)
(But in the meantime, whenever you see an indication of another
needed dep or bdep, pls add immediately)

Jean-Francois Mertens

PS: I attach the modified info file, pls remove the old one whenever
you've changed the new one as needed.
File Added: libxine1.info

> didn't know xine has some qt stuff in there. (it does have QuickTime
support though)

a "grep qt configure" gives:
echo " - mpeg_ts - qt/mpeg-4"

which seems to use mpeg-4 support from Qt. Is QuickTime using mpeg-4?

File Added: libxine1.info

changed --enable-macosx-video, SetCPPFLAGS, compile-script. Testing now.

> do you understand these configure params: (%m = powerpc)
--enable-altivec (%m = i386) --disable-altivec

According to the fink-documentation at
(http://www.finkproject.org/doc/packaging/reference.php) under
ConfigureParams, the condition works on the flag AFTER the test. So it's
"--enable-altivec" which is added on powerpc and "--disable-altivec" which
is added on 386, which seems to make sense.

The problem about the OpenGL is bizarre, I get it with fink, but not with
a local compilation! I tried really hard to copy exactly the same thing
locally as in fink, but to no avail. For some strange reason under fink
xine-lib wants to configure the mng-library. But if I add "--disable-mng"
it doesn't change anything :(
I added the supposed LDFLAG-parameter (according to some msgs) to the
info-file, but disabled it, because it doesn't even configure on my system
like that...

hi linus. looks already much better than the first version.

to enable the mac os x video, --enable-macosx-video has to be added to the
./configure call.

SetCPPFLAGS: -I%p/include -- I guess %p/include is the default, so it's
not needed

in the compile script:
- for i386 architecture, -UHAVE_MMX -UHAVE_MMX2 is added to the CPPFLAGS.
Is this important? I guess the configure script should figure this out
itself.
- for i386 archtecture, #define HAVE_DARWIN_CDROM 1 is added to config.
is this autodectected on PPC? if it is needed for at least on architecture,
it can be added anyway since we're 100% on a darwin platform.

do you understand these configure params: --enable-altivec (%m = i386)
--disable-altivec
=> on PPC altivec is disabled, and on i386 where it does not matter, it is
enabled and disabled at the same time?
I'm not sure about fink policy if altivec should be used. but as it should
be faster, maybe xine can compiled with run-time detection of altivec. I
can try that on G4 & G5.


I've got a compile error probably related to the "linking OpenGL on 10.5"
problem mentioned on the list and in the fink wiki somewhere (preparing for
10.5) while linking xineplug_vo_out_sdl.la:
ld: cycle in dylib re-exports with /usr/X11/lib/libGL.dylib


then, I guess we should try to figure out if some of the dependencies can
be removed. e.g. the dependency on qt3 looks strange to me. didn't know
xine has some qt stuff in there. (it does have QuickTime support though)

anyway.. I'll re-install XCode 3.0 and check a) if it builds at all, b) if
the dscaler_greedyh compiles.

matthias

File Added: libxine1.info

File Added: libxine1.info

File Added: libxine1.patch

File Added: libxine1.info

File Added: libxine1.info

File Added: libxine1.info

File Added: libxine1.patch