Big problems while compiling FFMPEG for iOS5 - objective-c

I'm trying to compile the ffmpeg library for iOS5. I tried different options but none works.
I downloaded this: https://github.com/ciphor/ffmpeg4ios .
I tried the original build_armv7 but it didn't work. I edited the build_arm7 file and now it looks like this:
#!/bin/tcsh -f
if (! -d armv7) mkdir armv7
if (! -d lib) mkdir lib
rm armv7/*.a
make clean
./configure --disable-network --disable-mpegaudio-hp --disable-lpc --disable-vaapi
--disable-vdpau --disable-hwaccels --disable-mmx --disable-mmx2 --disable-sse
--disable-ssse3 --disable-avx --disable-amd3dnow --disable-amd3dnowext --disable-vis
--disable-mmi --disable-doc --disable-yasm --disable-ffmpeg --disable-ffplay
--disable-ffprobe --disable-ffserver --disable-rdft --disable-dxva2 --disable-encoders
--disable-decoders --enable-decoder=h264 --disable-bsfs --disable-protocols
--disable-indevs --disable-outdevs --disable-devices --disable-filters --disable-demuxers --enable-demuxer=h264
--disable-muxers --disable-parsers --enable-parser=h264 --enable-cross-compile --arch=arm
--target-os=darwin
--cc=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin10-llvm-gcc-4.2 --as='gas-preprocessor/gas-preprocessor.pl /Aplications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin10-llvm-gcc-4.2'
--sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk --cpu=cortex-a8
--extra-cflags='-pipe -Os -gdwarf-2 -issysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk -m${thumb_opt:-no-thumb}
-mthumb-interwork' --extra-ldflags='-arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk' --enable-pic
make
mv libavcodec/libavcodec.a armv7/
mv libavdevice/libavdevice.a armv7/
mv libavformat/libavformat.a armv7/
mv libavutil/libavutil.a armv7/
mv libswscale/libswscale.a armv7/
rm lib/*.a
cp armv7/*.a lib/
But i get this error:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin10-llvm-gcc-4.2 is unable to create an executable file.
C compiler test failed.
I looked all over the Internet. I have read all the posts on stackoverflow about this but none helped me. Please tell me what i'm doing wrong and please don't post me links: trust me, i saw them all!

That worked for me with iOS 5.0 and Snow Leopard.
You have to change ldflags, sysroot and cc to provide valid paths to files in Mountain Lion
for Xcode was moved to antoher folder.
./configure \
--extra-ldflags=-L/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/lib/system \
--disable-muxers \
--disable-demuxers \
--disable-devices \
--disable-parsers \
--disable-protocols \
--disable-filters \
--disable-bsfs \
--disable-doc \
--disable-ffmpeg \
--disable-ffplay \
--disable-avfilter \
--disable-avformat \
--disable-ffserver \
--disable-decoders \
--disable-encoders \
--disable-network \
--enable-decoder=h261 \
--enable-decoder=h263 \
--enable-decoder=h263p \
--enable-encoder=h261 \
--enable-encoder=h263 \
--enable-encoder=h263p \
--enable-cross-compile \
--enable-hardcoded-tables \
--enable-memalign-hack \
--enable-neon \
--arch=arm \
--target-os=darwin \
--cc=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc \
--sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk \
--cpu=cortex-a8 \
--extra-cflags='-arch armv7 -mno-thumb -mfpu=neon -mfloat-abi=softfp' \
--extra-ldflags='-arch armv7 -mno-thumb -mfpu=neon -mfloat-abi=softfp' 2>&1 | tee configure.log
make clean
make

Inspect config.log file in your root compilation directory and search for "C compiler test failed.`' You will find right there the command that was tried and the exact reason why it failed (i.e., the compiler output).
It could be that the compiler installation directory is not /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/, or that some library cannot be found, etc...
Actually, what I see is that you are specifying on the configure command line a few paths. Have you checked that they are correct for your Xcode version?

If you require ffmpeg 11
You may need to use snow leopard or lion, Mountain lion seems to be missing critical gcc compiler components. We are looking into fixing our build scripts for this
If version isn't all that important to you, we have a pre-built framework for ffmpeg 8, really
we don't find any great difference between using the two and find that ffmpeg 8 has less performance issues.
https://github.com/mooncatventures-group/ffmpegDecoder
If you have a build box with lion or snow leopard you can probably modify our build script and build ffmpeg 11 , others have done this.

Related

LLVM ERROR: Cannot select: intrinsic %llvm.objc.clang.arc.use

I'm getting the next error with llc when trying to to link some IR files:
LLVM ERROR: Cannot select: intrinsic %llvm.objc.clang.arc.use
I discovered that if I disabled clang optimization (O0) during compilation the error doesn't pop up, but I don't want to do that
I attach a sample of how to reproduce it, just cd the 'issue' folder and run the 'issue.sh' to reproduce the error. You must have Xcode (12.x preferred) tu run it
https://drive.google.com/file/d/1j0TvMZI2A7QxRbv_Q7aydtlNYaiTPYBm/view?usp=sharing
This is what the issue.sh contains, that is a reduced version of my real implementation:
echo "clang..."
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c \
-target arm64-apple-ios12.0 \
-fobjc-arc -fmodules \
-S -Os -flto=thin \
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.1.sdk \
-fembed-bitcode \
-c ${PWD}/GTMSessionFetcher.m \
-o ${PWD}/GTMSessionFetcher.ll
echo "llc..."
${PWD}/llc \
GTMSessionFetcher.ll \
-stats -filetype=obj \
-code-model=small \
-enable-machine-outliner=never \
--mtriple=arm64-apple-ios12.0 \
-o ${PWD}/GTMSessionFetcher.o
As I mentioned before, if you change -Os for -O0, the error disappears, but I do need the size optimization.
The objective-c file that I included is a file from a pod from a Google library
https://github.com/google/gtm-session-fetcher
I found a similar question, but it doesn't have any answer yet
LLVM Error Cannot select intrinsic %llvm.coro.begin
I thought it was bug, but it wasn't
As Akira pointed me in LLVM bug report I was able to fix it by adding an intermediate optimizer OPT step with -objc-arc-contract flag:
clang
...
<path to your LLVM tools>/OPT \
<Your IR file> \
-objc-arc-contract \
-o <Output file>
llc
...

pgf77 vs pgf90 to compile software

I'm compiling a software (to convert ASCII to BIN) in LINUX, using PGI 2019 community version.
The Makefile use pgf77 which not included in the PGI compiler I have in my system, so I have to change to pgf90. However, I faced to an error:
pgf90 -vms -c -O -Mbyteswapio simcon.f
pgf90-Error-Unknown switch: -vms
make: *** [simcon.o] Error 1
I think the -vms is not recognized by pgf90. So what flag should I use here instead?
The MAKEFILE like this:
FCFLGS = -O -Mbyteswapio
OBJCTS = \
aircon.o \
airconv.o \
avgcon.o \
avgcns.o \
bndcon.o \
checon.o \
dfbcon.o \
emicon.o \
metcon.o \
ptscon.o \
regcon.o \
simcon.o \
tercon.o \
tmpcon.o \
tmpcn3.o \
tpccon.o \
wndcon.o
airconv: $(OBJCTS)
pgf77 -o airconv $(FCFLGS) $(OBJCTS)
.f.o:
pgf77 -c $(FCFLGS) $<
simcon.o: simcon.f
pgf77 -vms -c $(FCFLGS) simcon.f
Thank you very much.
Ha Chi
pgf77 was in the process of being deprecated with the PGI 2019 compilers. It's still there, but only included under the older non-LLVM versions of compilers (i.e. "$PGI/linux86-64-nollvm/19.xx/bin" directory). Though it would be best to move to the newer pgfortran driver (pgf90 works as well).
The "-vms" flag enabled very old VAX/VMS extensions that have been superseded by Fortran standard routines or other extensions. As you note, the code compiles without the flag, so either the code doesn't actually use these extensions or it can use the 3F version of the extensions.

Building LLVM with cmake. Does -D_GLIBCXX_USE_CXX11_ABI=0 get overridden?

I try to build LLVM.
This is the way I try …
mkdir -p src/llvm-$(LLVM_VERSION).src/build
cd src/llvm-$(LLVM_VERSION).src/build && \
$(CMAKE) -GNinja \
-DCMAKE_INSTALL_PREFIX=$(BUNDLE) \
-DCMAKE_CXX_FLAGS="-D_GLIBCXX_USE_CXX11_ABI=0 -std=c++11 -static-libgcc -static-libstdc++ -l:libstdc++.a" \
-DLLVM_TARGETS_TO_BUILD="X86;NVPTX" \
-DLLVM_PARALLEL_COMPILE_JOBS=$(BUILD_JOBS) \
-DLLVM_PARALLEL_LINK_JOBS=2 \
-DLLVM_USE_CRT_RELEASE=MD \
-DLLVM_USE_CRT_DEBUG=MDd \
-DLLVM_STATIC=ON \
-DLLVM_INCLUDE_TESTS=OFF \
-DLLVM_INCLUDE_EXAMPLES=OFF \
-DLLVM_BUILD_LLVM_C_DYLIB=OFF \
-DLLVM_ENABLE_TERMINFO=OFF \
-DLLVM_ENABLE_UNWIND_TABLES=OFF \
-DLLVM_ENABLE_RTTI=ON \
.. && \
$(CMAKE) --build . && \
$(CMAKE) --build . --target install
You can see -D_GLIBCXX_USE_CXX11_ABI=0 in -DCMAKE_CXX_FLAGS. After LLVM finished compiling, libLLVM*.a still contain abi:cxx11 symbols.
llvm-config reveals, llvm build process completely ignored "-D_GLIBCXX_USE_CXX11_ABI=0" flag.
> ./bundle/bin/llvm-config --cxxflags
-I/home/leonard/Documents/Develop/build_as_deps/bundle/include -std=c++11 -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
Do you have an idea how to build llvm in a way that disables abi:cxx11 symbols and prevents "-D_GLIBCXX_USE_CXX11_ABI=0" to be overridden?
It looks like you're confusing the cmake options (which are specified with via -D) with C/C++ compiler macro (which are also specified via -D, but to compiler). cmake happily ignored your -D_GLIBCXX_USE_CXX11_ABI, because it's not a cmake option (and you should see a warning about this, that the value is unused by the build system).
Since you need to add extra macro definition, you'd need to change CMAKE_CXX_FLAGS cmake variable.

Compiling Ceph on CentOS 5: `doc_DATA' is used but `docdir' is undefined?

Has anyone sucessfully compiled Ceph on the CentOS 5?
[user#host ceph-0.56.4]# make
...
checking boost/spirit.hpp usability...
src/Makefile.am:1115: `doc_DATA' is used but `docdir' is undefined
make: *** [Makefile.in] Error 1
make: *** Waiting for unfinished jobs....
yes
Line 1115 in the src/Makefile.am:
# work around old versions of automake that don't define $docdir
# NOTE: this won't work on suse, where docdir is /usr/share/doc/packages/$package.
docdir ?= ${datadir}/doc/ceph
doc_DATA = $(srcdir)/sample.ceph.conf sample.fetch_config
I have tried to change the docdir to the absolute path:
docdir = /usr/share/doc/ceph
but it doesn't help.
# rpm -qa | grep automake
automake16-1.6.3-8.el5.1
automake15-1.5-16.el5.2
automake-1.9.6-2.3.el5
automake17-1.7.9-7.el5.2
automake14-1.4p6-13.el5.1
What surprised me is in the ceph.spec, I see:
%{configure} CPPFLAGS="$java_inc" \
--prefix=/usr \
--sbindir=/sbin \
--localstatedir=/var \
--sysconfdir=/etc \
--docdir=%{_docdir}/ceph \
--without-hadoop \
--with-nss \
--without-cryptopp \
--with-rest-bench \
--with-debug \
--enable-cephfs-java \
$MY_CONF_OPT \
%{?_with_ocf} \
%{?with_tcmalloc:--with-tcmalloc} %{!?with_tcmalloc:--without-tcmalloc} \
CFLAGS="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS"
but there is no --docdir configure option when searching through the ./configure --help.
I know CentOS 5 is quite old but is there any workaround in this situation?
UPDATE Thu Apr 4 23:05:53 ICT 2013
Ceph 0.46 was compiled successfully, but now I get:
# ceph-fuse --no-fuse-big-writes -m 192.168.2.15:6789 /mnt/ceph/
ceph-fuse[7528]: starting ceph client
ceph-fuse[7528]: starting fuse
fuse: unknown option `atomic_o_trunc'
2013-04-04 13:51:21.128506 2b82d6e9e8f0 -1 fuse_lowlevel_new failed
ceph-fuse[7528]: fuse finished with error 33
ceph-fuse[7526]: mount failed: (33) Numerical argument out of domain
http://tracker.ceph.com/issues/4286
While none of the kernel clients will work, ceph used to run on CentOS 5. There is, of course, a chance that some nasty build issues have been introduced though. I know we test packages for RHEL/CentOS 6 ( http://ceph.com/rpm/el6/ ), but I don't think anyone has looked at 5 in a while.
When it was being built on 5 I know there were a bunch of dependencies if you get that far:
autotools-dev
autoconf
automake
cdbs
g++
gcc
git
libatomic-ops-dev
libboost-dev
libcrypto++-dev
libcrypto++
libedit-dev
libexpat1-dev
libfcgi-dev
libfuse-dev
libgoogle-perftools-dev
libgtkmm-2.4-dev
libtool
pkg-config
Sorry I can't answer your question specifically, but it has been quite a while since anyone around here looked at Ceph on Cent5. If you stop by irc://irc.oftc.net/ceph someone might be able to give you a better historical perspective than I can.
Good luck.
[EDIT]: Just talked to someone who went through and made it work. He had this to say: "It took compiling GCC, all of the GNU libs, autoconf, automake, probably about 10-20 other libraries and of course ceph itself." So, it's possible...just not recommended. Hope that helps.

NetBeans doesn't recognize Makefile.am

I'm coming from a Objective-C/Xcode background.
I'm used to working with C projects already imported into XCode, but now I want to analyse an existing implementation of an algorithm I'm interested in integrating with my project.
Only that this project is written completely in C and has nothing to do with Objective-C/Xcode etc.
I'm not sure what is the best way to view a purely C project on Mac, so I installed NetBeans for C/C++.
The problem is that when I try to create a New Project on NetBeans and select C/C++ Project with Existing Sources it complains that
no make files or configure scripts were found
in the root directory.. although it clearly has a Makefile.am
I know that the Balsa project is written for linux, but I'm not interested in building the binary I just want to look at the source code in a IDE kinda way (ie I can click on a function call and see where it's implemented etc etc).
So in short my question is why isn't NetBeans recognising my Makefile.am?
and just for reference here is the content of the Makefile.am
#intl dir needed for tarball --disable-nls build.
DISTCHECK_CONFIGURE_FLAGS=--disable-extra-mimeicons --without-gnome --without-html-widget
SUBDIRS = po sounds images doc libbalsa libinit_balsa src
# set tar in case it is not set by automake or make
man_MANS=balsa.1
pixmapdir = $(datadir)/pixmaps
pixmap_DATA = gnome-balsa2.png
desktopdir = $(datadir)/applications
desktop_in_files = balsa.desktop.in balsa-mailto-handler.desktop.in
desktop_DATA = balsa.desktop balsa-mailto-handler.desktop
#INTLTOOL_DESKTOP_RULE#
balsa_extra_dist = \
GNOME_Balsa.server.in \
HACKING \
balsa-mail-style.xml \
balsa-mail.lang \
balsa.1.in \
balsa.spec.in \
bootstrap.sh \
docs/mh-mail-HOWTO \
docs/pine2vcard \
docs/vconvert.awk \
$(desktop_in_files) \
gnome-balsa2.png \
intltool-extract.in \
intltool-merge.in \
intltool-update.in \
mkinstalldirs
if BUILD_WITH_G_D_U
balsa_g_d_u_extra_dist = gnome-doc-utils.make
endif
if !BUILD_WITH_UNIQUE
serverdir = $(libdir)/bonobo/servers
server_in_files = GNOME_Balsa.server
server_DATA = $(server_in_files:.server.in=.server)
$(server_in_files): $(server_in_files).in
sed -e "s|\#bindir\#|$(bindir)|" $< > $#
endif
EXTRA_DIST = \
$(balsa_extra_dist) \
$(balsa_g_d_u_extra_dist)
if BUILD_WITH_GTKSOURCEVIEW2
gtksourceviewdir = $(BALSA_DATA_PREFIX)/gtksourceview-2.0
gtksourceview_DATA = balsa-mail.lang \
balsa-mail-style.xml
endif
DISTCLEANFILES = $(desktop_DATA) $(server_DATA) \
intltool-extract intltool-merge intltool-update \
gnome-doc-utils.make
dist-hook: balsa.spec
cp balsa.spec $(distdir)
#MAINT#RPM: balsa.spec
#MAINT# rm -f *.rpm
#MAINT# $(MAKE) distdir="$(PACKAGE)-#BALSA_VERSION#" dist
#MAINT# cp $(top_srcdir)/rpm-po.patch $(top_builddir)/rpm-po.patch
#MAINT# rpm -ta "./$(PACKAGE)-#BALSA_VERSION#.tar.gz"
#MAINT# rm $(top_builddir)/rpm-po.patch
#MAINT# -test -f "/usr/src/redhat/SRPMS/$(PACKAGE)-#VERSION#-#BALSA_RELEASE#.src.rpm" \
#MAINT# && cp -f "/usr/src/redhat/SRPMS/$(PACKAGE)-#VERSION#-#BALSA_RELEASE#.src.rpm" .
#MAINT# -for ping in /usr/src/redhat/RPMS/* ; do \
#MAINT# if test -d $$ping ; then \
#MAINT# arch=`echo $$ping |sed -e 's,/.*/\([^/][^/]*\),\1,'` ; \
#MAINT# f="$$ping/$(PACKAGE)-#VERSION#-#BALSA_RELEASE#.$$arch.rpm" ; \
#MAINT# test -f $$f && cp -f $$f . ; \
#MAINT# fi ; \
#MAINT# done
#MAINT#snapshot:
#MAINT# $(MAKE) distdir=$(PACKAGE)-`date +"%y%m%d"` dist
#MAINT#balsa-dcheck:
#MAINT# $(MAKE) BALSA_DISTCHECK_HACK=yes distcheck
## to automatically rebuild aclocal.m4 if any of the macros in
## `macros/' change
bzdist: distdir
#test -n "$(AMTAR)" || { echo "AMTAR undefined. Run make bzdist AMTAR=gtar"; false; }
-chmod -R a+r $(distdir)
$(AMTAR) chojf $(distdir).tar.bz2 $(distdir)
-rm -rf $(distdir)
# macros are not used any more by current configure.in, see also
# post by Ildar Mulyukov to balsa-list, 2006.06.27
# ACLOCAL_AMFLAGS = -I macros
UPDATE
I tried this answer.. but I got the following:
autoreconf --install
configure.in:250: warning: macro `AM_GLIB_GNU_GETTEXT' not found in library
glibtoolize: putting auxiliary files in `.'.
glibtoolize: copying file `./ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
glibtoolize: copying file `m4/libtool.m4'
glibtoolize: copying file `m4/ltoptions.m4'
glibtoolize: copying file `m4/ltsugar.m4'
glibtoolize: copying file `m4/ltversion.m4'
glibtoolize: copying file `m4/lt~obsolete.m4'
glibtoolize: Remember to add `LT_INIT' to configure.in.
glibtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
glibtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT'
configure.in:250: warning: macro `AM_GLIB_GNU_GETTEXT' not found in library
configure.in:249: error: possibly undefined macro: AC_PROG_INTLTOOL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.in:250: error: possibly undefined macro: AM_GLIB_GNU_GETTEXT
configure.in:301: error: possibly undefined macro: AC_MSG_ERROR
autoreconf: /usr/bin/autoconf failed with exit status: 1
I'm looking into using the suggestions in the output..
Interesting. I just tried downloading "balsa" and noticed that they distributed the Makefile.am and configure.in files instead of a ready to run configure script. You could let the package maintainers know they aren't doing anyone any favors by not precompiling their own autotools sources.
Makefile.am is not a real Makefile. It's the thing that generates Makefile.in, which in turn gets translated into a real Makefile by a configure script.
Try the following steps:
Download the sources to balsa again clean. Then from the command prompt type the following:
autoreconf --install
(If you don't have autoreconf, you likely need to install the autotools packages - ughh...)
That should generate the configure script. Then type:
./configure
It complained about some missing GMime dependencies, so I didn't see it actually generate a Makefile. Once you get to the point in which a Makefile is generated, you should be able to point Netbeans to "open project from existing sources".
As per abbood's request...
Netbeans is not very good for C development. One approach would be to build an XCode project around the source base. The maintainers of the project may even accept the XCode project as a contribution.