v0.8.4+ won't build in OSX (10.7.5)

[mraaroncruz]

v0.8.4+ won't build in OSX (10.7.5)

[ddennedy]

I have a build server that has been building MLT on OS X on a nightly basis for a while now not to mention I maintain a port for mlt in MacPorts for many years. So, it does build, and I am not going to help you with this much. First, you must consider that old versions of MLT might not compile with clang. However, the problem you are seeing might be that it is when linking mlt++, it is linking against the installed version of libmlt and not the one currently being built. You can 'make -C src/framework install' and then resume normal make to see if the problem goes away. Or, you can uninstall the existing version and verify all old versions are removed before proceeding.

[mraaroncruz]

You are correct, when I cleared out the old dylibs/headers, like I should have, it compiled.
But I am still having a problem getting SWIG ruby to build (and have never gotten python to build, though it works on debian/ubuntu)

cc -dynamiclib -o ../libmltxml.dylib factory.o consumer_xml.o producer_xml.o -L../../framework -lmlt -lpthread -L/usr/local/lib -lSDLmain -lSDL -Wl,-framework,Cocoa `pkg-config libxml-2.0 --libs`
list='ruby'; \
    for subdir in $list; do \
        if [ -x $subdir/build -a ! -f .$subdir -o all = clean ] ; \
        then echo -n Building $subdir... ; \
            cd $subdir && output=`CXXFLAGS="" ./build all 2>&1` ; \
            if [ $? -eq 0 ] ; \
            then echo OK && touch ../.$subdir ; \
            else echo $output && exit 1 ; \
            fi ; \
            cd .. ; \
            if [ -f $subdir/Makefile -a -f .$subdir ] ; \
            then make -C $subdir all || exit 1 ; \
            fi ; \
            if [ all = clean ] ; \
            then rm -f .$subdir ; \
            fi ; \
        fi \
    done
-n Building ruby...
OK
linking shared-object mlt.bundle
ld: file not found: /usr/local/lib/libmlt.5.dylib for architecture x86_64
collect2: ld returned 1 exit status
make[2]: *** [mlt.bundle] Error 1
make[1]: *** [all] Error 1
make: *** [all] Error 1

I am not asking you for help. I am just making you aware of a "bug" that I found. Thank you for your help though. There are some things I would like to ask help for and other "bugs" that I would like to report but I often receive a stony, irritated sounding response which is very discouraging.

[ddennedy]

When I ran the ruby build I got this:

cc -arch i386 -arch x86_64 -pipe -bundle -undefined dynamic_lookup -o mlt.bundle mlt_wrap.o -L. -L/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib -L. -arch i386 -arch x86_64  -L../../mlt++ -lmlt++    -lruby  -lpthread -ldl -lobjc  
ld: warning: ignoring file ../../mlt++/libmlt++.dylib, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): ../../mlt++/libmlt++.dylib

My MLT build is not building i386, so I just edited the Makefile removing 3 occurrences of "-arch i386" near the top, and ran make. It succeeded and is working (except sdl consumer, which has special needs on OS X). I am not sure why your build is looking in /usr/local/lib; mine looked in ../../. Maybe the libmlt is not actually in /usr/local/lib since you cleaned it out. You could try ignoring the error, run make install, then cd src/swig/ruby and run make in there to complete it. Python works fine for me with no tweaking, but I am using MacPorts, and maybe that affected it.

I tell everyone else that I do not provide build support. So, despite the feeling that you get, I am going way beyond what I normally provide - and for someone who I know who is not working on an open source project.

[mraaroncruz]

The fact that the software that I am working on is not open source is irrelevant. We have offered you consulting and the only other way to get help/file bugs is to ask here or the mailing list. So what you're saying sounds like "Become a C hacker or get out of here noob", which is the route that I ended up taking.

Even with the feeling that I get, you do respond faster and with better information than most, if not all, OSS project developers I have submitted issues with (myself included). And even when it sounds like you are saying "Don't waste my time", you always provide some kind of workable solution. So thank you very much for that. I know how much time it takes to even read and consider these issues, I appreciate it greatly.

Thank you.