Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I haven't been able to successfully build it, but I've overcome some hurdles which might be useful.</p> <h1>Hurdle 1: ARM Thumb2</h1> <p><em>Summary</em>: Even though advertised as fully supporting <code>thumb</code>, it appears Apple's provided <code>clang</code>, as well as <code>LLVM 3.2</code>'s one fail to translate some valid <code>thumb</code> instructions which appear in <code>libav</code>'s ARM-assembler code. </p> <p><em>Details</em>: <code>libav</code> (a fork of <code>ffmpeg</code>) has some functionality implemented in assembler. When building for iOS, files from <code>MobileVLC/ImportedSources/vlc/contrib/iPhoneOS/ffmpeg/libavcodec/arm</code> are used. The first compile error one will probably encounter is something similar to </p> <pre><code>libavcodec/arm/aacpsdsp_neon.S:132:21: error: invalid operand for instruction add r4, r0, #38*64*4 </code></pre> <p>According to <a href="http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001l/QRC0001_UAL.pdf" rel="noreferrer">ARM Thumb2's reference</a>, the above instruction is a valid <code>ADD{S} Rd, Rn, &lt;Operand2&gt;</code> instruction, where <code>&lt;Operand2&gt;</code> in <code>thumb</code> mode is "a 32-bit constant, formed by left-shifting an 8-bit value by any number of bits". Since <code>#38*64*4</code> equals 38 left-shifted 8 times, <code>clang</code> should accept it. It seems that <code>clang</code> won't recognize it's possible, therefore attempting to interpret the instruction as a <code>ADD Rd, Rn, #&lt;imm12&gt;</code> one, for which the immediate argument must be smaller than 4096. </p> <p>If somebody with more confidence on the subject can relate - is it a bug in <code>clang</code>?</p> <p><em>Workaround</em>: As noted in <a href="http://forum.videolan.org/viewtopic.php?f=12&amp;t=103271" rel="noreferrer">http://forum.videolan.org/viewtopic.php?f=12&amp;t=103271</a>, <code>thumb</code> should be disabled when configuring <code>ffmpeg</code> (which is in fact <code>libav</code>).</p> <h1>Hurdle 2: libtool cannot infer tag</h1> <p><em>Summary</em>: <code>MobileVLC</code>'s <code>libtool</code> is configured to infer C++ compilations, which expects an invokation of <code>clang++</code>. When the build system calls <code>gas-preprocessor.pl xcrun clang</code> instead, <code>libtool</code> throws an error.</p> <p><em>Details</em>: <code>MobileVLC</code> configures a copy of <code>libtool</code> (which is just a bash script) at <code>MobileVLC/ImportedSources/vlc/build-ios-OS</code>. On line 1681, the function <code>func_infer_tag</code> is responsible for, well, inferring the tag. For each tag that appears in the variable <code>$available_tags</code> defined on line 38, <code>libtool</code> itself is searched for a tag configuration section. For example, the CXX (=C++) tag configuartion begins on line 9258. As can be seen on line 9271, the compiler command which is expected of a C++ compilation is <code>xcrun clang++</code>. </p> <p>The build system calls something like <code>libtool --mode=compile gas-preprocessor.pl xcrun clang …</code>, and since <code>xcrun clang++</code> does not prefix the command, the C++ mode cannot be inferred. (<code>gas-preprocessor.pl</code> translates GNU Assembler into something Apple's assembler can work with)</p> <p><em>Workaround</em>: As noted in <a href="http://forum.videolan.org/viewtopic.php?f=12&amp;t=103331" rel="noreferrer">http://forum.videolan.org/viewtopic.php?f=12&amp;t=103331</a>, <code>MobileVLC/ImportedSources/vlc/modules/video_filter/Modules.am</code> can be modified to force <code>libtool</code> to infer a C compilation. If it doesn't work for you, like it didn't for me, you can call <code>libtool</code> yourself.</p> <p><code>cd</code> into <code>MobileVLC/ImportedSources/vlc/build-ios-OS/modules/video_filter</code>; typing <code>make</code> should cause the error to appear. Typing <code>make V=1</code> will also show the command being executed. It will start with <code>source='deinterlace/merge_arm.S' o…</code>. You can now copy it and call it manually, adding <code>--tag=CC</code> after <code>../../libtool</code>. </p> <h1>Hurdle 3: CopyStringsFile</h1> <p><em>Summary</em>: Building <code>MobileVLC</code> fails with the error,</p> <pre><code>The following build commands failed: CopyStringsFile build/Release-iphoneos/VLC.app/pl.lproj/Localizable.strings Resources/pl.lproj/Localizable.strings </code></pre> <p><em>Details</em>: The offending file, <code>MobileVLC/Resources/pl.lproj/Localizable.strings</code> is a UTF-16-LE file missing a byte-order-mark (BOM), which confuses Xcode for some reason.</p> <p><em>Workaround</em>: <code>cd</code> into <code>MobileVLC/Resources/pl.lproj/</code> and execute</p> <pre><code>mv -n Localizable.strings Localizable.strings.backup &amp;&amp; python -c "import sys; sys.stdout.write(chr(0xFF)+chr(0xFE))" &gt; Localizable.strings &amp;&amp; cat Localizable.strings.backup &gt;&gt; Localizable.strings </code></pre> <p>This will add the BOM to the beginning of the file.</p> <h1>Hurdle 4: <code>non_lazy_ptr</code> + <code>AmplifyFloat</code></h1> <p><em>Summary</em>: This error should read: "An internal data structure of the linker <code>ld</code> has a non-lazy pointer which contains the address of a symbol <code>ld</code> cannot find". The missing symbols cannot be found because they are not prefixed with an underscore.</p> <p><em>Details</em>: It is obviously a shame that <code>ld</code> won't indulge us with the knowledge of <em>what</em> exactly it can't find, but we're not here to rant. </p> <p>Consider the following simple <code>bla.c</code> file,</p> <pre><code>int bla(); int foo() { return bla(); } </code></pre> <p>Compiling this file (<code>clang -c bla.c</code>) and then listing its symbols (<code>nm bla.o</code>) reveals that the linker expects some other compilation unit to provide the symbol <code>_bla</code> (note the underscore). The underscore is presumably added to signify <code>bla</code> should be called in the C calling convention. The problem arises when <code>bla</code> is defined in an assembler file; the assembler does not add an underscore, resulting in a <code>bla</code> symbol, leading to linking failure.</p> <p>An interesting detail is that this behaviour is different to Linux, where an underscore is not added to symbol names, which probably helped the problem escape the attention of VLC's devs. Still, the underscoring behavior appears in MinGW as far as I know, so the solution could be similar.</p> <p><em>Workaround</em>: The simplest solution, even if ad-hoc, is to use a symbol alias list. Create a file <code>symbol-alias.txt</code> with the following contents,</p> <pre><code>merge16_arm_neon _merge16_arm_neon merge8_arm_neon _merge8_arm_neon amplify_float_arm_neon _amplify_float_arm_neon </code></pre> <p>This file is enough depending on flags and configurations; it was enough for me, though. Type <code>open MobileVLC.xcodeproj</code> when in the <code>MobileVLC/</code> directory. This should laungh Xcode. In project settings, choose the <code>MobileVLC</code> target, and then <code>Build Settings</code>. In <code>Other Linker Flags</code>, add </p> <pre><code>-Wl,-alias_list -Wl,&lt;absoluate-path-to-symbol_aliases.txt&gt; </code></pre> <p>Save and build. Congratulations. You now have reached the Hurdle I don't know how to overcome :)</p> <h1>Hurdle 5: Address not in any section</h1> <p><em>Summary</em>: The linker fails with the cryptic error</p> <pre><code>ld: in section __TEXT,__text reloc 13: sectionForAddress(0xE142) address not in any section for architecture armv7 </code></pre> <p>I'm not sufficiently familiar with linking to figure out what's wrong, but I guess it all boils down to code written in assembler.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload