3
votes

I'm trying to port FLAC encoder using Adobe Alchemy for use in flash but can't figure out where the problem is.
I'm using Alchemy for Cygwin on Windows. It is properly installed and configured.
The following are the steps that I have followed in order to port FLAC encoder:

  1. Download the latest version of FLAC sources (1.2.1)
  2. Configure FLAC sources (./configure --enable-static=true --enable-shared=false) with the alchemy enabled (alc-on before configure)
  3. Compile libFLAC with the alchemy enabled (make in src/libFLAC folder)
  4. Copy header files and compiled static library (libFLAC.a) to alchemy folders (${ACLHEMY_HOME}/usr/local/include and ${ACLHEMY_HOME}/usr/local/lib respectively)
  5. Finally, compile SWC in that way:
    gcc encodeflac.c -O3 -Wall -swc -lFLAC -o encodeflac.swc
    or (whatever)
    gcc encodeflac.c -O3 -Wall -swc -lflac -o encodeflac.swc

encodeflac.c is the modified version of example included in FLAC sources (examples/c/encode/file/main.c) and adopted to work with ActionScript ByteArrays.

The swc will compile without warnings or errors. But the final swc size is only 85kb, while the static library size (libFLAC.a) is about 1mb! Also, the encoding is not working. I get the following error when trying to use it in AS:
[Fault] exception, information=Undefined sym: FLAC_stream_encoder_new

Does it mean that the static library is not included in swc? Why?

Thanks in advance.

2

2 Answers

1
votes

Alchemy's swc linker doesn't have very good error reporting, which makes debugging it hard. What's happening is that the linker isn't finding the lib. How to fix it:

  1. gcc is case-sensitive. You must use -lFLAC (not -lflac)
  2. alchemy needs the FLAC.l.bc file that was generated when you built libFLAC.a

Unfortunately, getting it to actually link ends up producing a link-time error:

Cannot yet select: 0x198b960: i32 = ConstantPool < i64 6881500230622117888> 0
0   llc                                 0x00636dfe _ZNSt8_Rb_treeIN4llvm3sys4PathES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE13insert_uniqueERKS2_ + 6078
1   llc                                 0x006373a2 _ZNSt8_Rb_treeIN4llvm3sys4PathES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE13insert_uniqueERKS2_ + 7522
2   libSystem.B.dylib                   0x9402f2bb _sigtramp + 43
3   ???                                 0xffffffff 0x0 + 4294967295
4   libSystem.B.dylib                   0x940a323a raise + 26
5   libSystem.B.dylib                   0x940af679 abort + 73
6   llc                                 0x002f862b _ZN98_GLOBAL__N__Volumes_data_dev_FlaCC_llvm_2.1_lib_Target_AVM2_AVM2ISelDAGToDAG.cpp_00000000_F04616B616AVM2DAGToDAGISel10SelectCodeEN4llvm9SDOperandE + 187
7   llc                                 0x002fa193 _ZN98_GLOBAL__N__Volumes_data_dev_FlaCC_llvm_2.1_lib_Target_AVM2_AVM2ISelDAGToDAG.cpp_00000000_F04616B616AVM2DAGToDAGISel10SelectRootEN4llvm9SDOperandE + 819
8   llc                                 0x002e6a2c _ZN4llvm19X86_64TargetMachineD0Ev + 65116
9   llc                                 0x003de4ca _ZN4llvm11StoreSDNodeD1Ev + 1610
10  llc                                 0x0040d3fe _ZN4llvm11StoreSDNodeD1Ev + 193918
11  llc                                 0x0040f92e _ZN4llvm11StoreSDNodeD1Ev + 203438
12  llc                                 0x005d1926 _ZN4llvm12FunctionPassD1Ev + 20998
13  llc                                 0x005d1f3a _ZN4llvm12FunctionPassD1Ev + 22554
14  llc                                 0x005d20c5 _ZN4llvm12FunctionPassD1Ev + 22949
15  llc                                 0x00002e44 _mh_execute_header + 7748
16  llc                                 0x00001f36 _mh_execute_header + 3894
17  ???                                 0x00000006 0x0 + 6

I saw this same error when trying to build libFLAC (v1.2.1) as a whole (not just the library). This error happens when there's some kind of C code that produces LLVM bytecode that Alchemy can't handle. (It's unclear if this is a problem with what LLVM produces or a bug with Alchemy.)

You have to figure out where the offending code is and change it into something that Alchemy likes (without actually changing the logic!). I seem to remember someone having a similar problem with ffmpeg: http://forums.adobe.com/message/2905914#2905914

1
votes

Took me a while but I managed to track down the linking error to this assignment on line 956 in stream_encoder.c (version 1.2.1):

encoder->private_->local_fixed_compute_best_predictor = FLAC__fixed_compute_best_predictor_wide

It actually seems to have something to do with the symbol name of the wide method. Haven't figured out a good solution yet. I'll amend my answer when I do. Do note that this is only an issue if the block size is too big (more than 4096 at 16 bits), which by default never is the case, so you can safely comment out the assignment and not deal with the real problem...

And just a heads up: when you are actually using the Flac library and all you're getting is zeros, check the SWAP_BE_WORD_TO_HOST macro in bitwriter.c. For some reason ntohl is only returning zeros. Try defining your own endianness swapper like this:

#define SWAP_BE_WORD_TO_HOST(x) (x<<24|(x&0x0000FF00)<<8|(x&0x00FF0000)>>8|x>>24)

Hope it helps anyone trying to get the Flac lib to compile in alchemy.