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:
Download the latest version of FLAC sources (1.2.1)
Configure FLAC sources (./configure --enable-static=true --enable-shared=false) with the alchemy enabled (alc-on before configure)
Compile libFLAC with the alchemy enabled (make in src/libFLAC folder)
Copy header files and compiled static library (libFLAC.a) to alchemy folders (${ACLHEMY_HOME}/usr/local/include and ${ACLHEMY_HOME}/usr/local/lib respectively)
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.
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:
gcc is case-sensitive. You must use -lFLAC (not -lflac)
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
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.
Related
(There is another post here in Stackoverflow: (Which version of m4 does the author of Debugging with GDB use?), but answer referred links are broken and the solution doesn't look much deep or to the point. I have to say i tried them and also tried to look in other m4 versions in the gnu repository, but even that: "len_lquote = strlen(lquote);" looks deprecated since 2006 version, oldest i found).
VERY EASY EXPLANATION: first example in Stallman GDB book refers to a "./m4" executable (first weird sensation with that "./"), allegedly to be present in some (some old standard installation, perhaps?):
/gnu/m4 (?)
or
/work/Editorial/gdb/gnu/m4/ (?)
(and as i pointed, it looks to be executed with './' like it was indeed not like an environment executable [like mine. My "m4" that i installed through "sudo apt install m4" for the purpose]).
The problem is that if i run "gdb m4", it doesn't do the anything similar with the book's m4:
SHOULD BE (for example, setting a breakpoint in a KNOWN function. KNOWN, because i guess it should be some .c or something like that that GDB should load/consult in parallel with the executable, no?):
(gdb) break m4_changequote
Breakpoint 1 at 0x62f4: file builtin.c, line 879.
MINE:
$ gdb m4
GNU gdb (Debian 12.1-4+b1) 12.1 Copyright (C)
2022 Free Software Foundation, Inc. (......) Reading symbols from
m4... (No debugging symbols found in m4)
(gdb) break m4_changequote
Function "m4_changequote" not defined. Make breakpoint pending on
future shared library load? (y or [n]) n
Any USEFUL (direct to the point) help?
Any SOLUTION?
Any EQUIVALENT path?
VERY EASY EXPLANATION: first example in Stallman GDB book refers to a "./m4" executable (first weird sensation with that "./"), allegedly to be present in some (some old standard installation, perhaps?)
You are coming to this problem with the wrong set of assumptions.
In general, you most often use GDB on your own programs, i.e. programs you coded yourself. You usually debug these programs in the directory in which you built them, which is the current directory. On UNIX, current directory is named ., and if you want to refer to a program in your current directory, you use ./program notation.
In the book, Stallman is debugging m4 which he worked on and built.
You are trying to debug m4 which you didn't build, and thus you are having problems following the book.
I suggest that you actually download m4 sources and build it yourself (it should be as simple as ./configure && make), and then follow the book.
Debugging the system-provided m4 is also possible, but that's not what the book is about.
Update:
I did my homework and went through many files (.c, .h, etc) in many folders of m4 versions and i couldn't find anything like what you pointed back in your 2009 post: "...You can download any version of m4, change len_lquote = strlen(lquote); to len_lquote = strlen(rquote); in set_quotes(), and then redo the sample debugging session. ...".
The 2009 post referenced above is apparently this one.
I downloaded m4 version using:
git clone git://git.sv.gnu.org/m4
cd m4
git checkout branch-1.4
In src/input.c, I see this code:
719 void
720 set_quotes (const char *lq, const char *rq)
721 {
722 free (lquote.string);
723 free (rquote.string);
724
725 /* POSIX states that with 0 arguments, the default quotes are used.
726 POSIX XCU ERN 112 states that behavior is implementation-defined
727 if there was only one argument, or if there is an empty string in
728 either position when there are two arguments. We allow an empty
729 left quote to disable quoting, but a non-empty left quote will
730 always create a non-empty right quote. See the texinfo for what
731 some other implementations do. */
732 if (!lq)
733 {
734 lq = DEF_LQUOTE;
735 rq = DEF_RQUOTE;
736 }
737 else if (!rq || (*lq && !*rq))
738 rq = DEF_RQUOTE;
739
740 lquote.string = xstrdup (lq);
741 lquote.length = strlen (lquote.string);
742 rquote.string = xstrdup (rq);
743 rquote.length = strlen (rquote.string);
744 }
Obviously there is no longer len_lquote = strlen(lquote);, but the equivalent statement is now lquote.length = strlen (lquote.string); on line 741.
To introduce a bug, you would change line 741 to read lquote.length = strlen (rquote.string);
But suppose you really want the source to match what was described in the book. The book was first published in 1988, and the very first version of input.c in the Git repo is from 2000, so we need to find older version of m4 sources.
I found a reference to m4-1.0.3.tar.Z from 1992 here, and the file itself here: http://www.nic.funet.fi/index/gnu/funet/historical-funet-gnu-area-from-early-1990s/m4-1.0.3.tar.Z
In that TAR file, m4-1.0.3/input.c does have the source you are looking for:
555 void
556 set_quotes (char *lq, char *rq)
557 {
558 if (lquote != def_lquote)
559 xfree (lquote);
560 if (rquote != def_rquote)
561 xfree (rquote);
562
563 lquote = (lq == NULL) ? def_lquote : xstrdup (lq);
564 rquote = (rq == NULL) ? def_rquote : xstrdup (rq);
565
566 len_lquote = strlen (lquote);
567 len_rquote = strlen (rquote);
568 }
Beware: that source is very old and does not build with modern compilers (GCC-12.2.0 in my case). You'll need to get an ancient version of GCC to build it.
I am playing around with GNU APL, but my experiments quickly reached an impasse.
This is what happened:
x←1 2 3 4 5
⍝ build the matrix u where u_{ij} = x_i + x_j,
⍝ then filter the entries equal to 6
u←6=x∘.+x
So far so good, u is a flipped identity matrix, as expected.
Now, I would like to get the indices of the nonzero entries, so I try
⍸u
but here I get a SYNTAX ERROR++ warning.
The same error appears when entering any of the following commands:
{⍸6=⍵∘.+⍵}x
{⍸6=⍵∘.+⍵} 1 2 3 4 5
{⍸6=⍵∘.+⍵} ⍳5
app←{⍸6=⍵∘.+⍵}
I suspect this is somehow a problem on my local installation, as I cannot reproduce the errors on the online interpreter.
Did somebody see this problem before?
I compiled APL from source (ubuntu, GCC), the error appears in both versions 1.7 and 1.8.
I could reproduce the error with the precompiled binary available from GNU's mirror.
I wonder if I made a mistake in compiling and installing GNU APL, but the only non-standard thing I did was to unset the flag WERROR from the Makefile in the src folder, otherwise it would not compile due to an unchecked return value in the source.
I emailed bug-apl#gnu.org to get someone to have a look. This is the response I got:
no idea. I am getting this:
⍝ build the matrix u where u_{ij} = x_i + x_j,
⍝ then filter the entries equal to 6
u←6=x∘.+x
⍸u 1 5 2 4 3 3 4 2 5 1
SVN is 18005 aka. 1474 and the related code has not changed für years.
Regarding:
"otherwise it would not compile due to an unchecked return value in
the source."
please report this kind of problems to bug-apl#gnu.org with a printout
of the compiler's error message. Compilers are becoming increasingly
picky about various this which causes code to happily compile for a
decade an then out of a sudden raise a warning with a new compiler
code.
I have the ambition that GNU APL compiles on almost all platforms and
compilers and since I cannot test all platforms on my own it is
important that users like you with a different platform inform me
about problems.
Best Regards,
[Dr.] Jürgen [Sauermann, the main developer of GNU APL]
Edit per the GNU APL mailing list:
Support for ⍸ was added in December 2020 (r1368). Released tarballs don't have it; you will have to compile the development version from the repository to get it.
Note that tarballs are not the preferred way of installing GNU APL.
My application is crashing when built on a new Apple laptop and then launched on a much older Apple laptop.
The application is built using Xcode 6.4, on OSX 10.9 and 10.10, when using llvm 6.1 and C++11. The SDK is 10.10, the target OSX is 10.7. Optimizations are off.
The crash is very very early on when the C runtime is loading my application binary and initializing the modules.
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.MyCompany.MyApplication 0x000000010cd10e7a _GLOBAL__I_a + 10
1 dyld 0x00007fff61fd3ceb ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 265
2 dyld 0x00007fff61fd3e78 ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
3 dyld 0x00007fff61fd0871 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int,
This is before any of my application code. The crash does not occur on the build machine (i7 CPU). Crashes occur on i5 and Core 2 Duo machines. I suspect that an extended (CPU specific) instruction is creating the crash on load.
When I use the same Xcode, same llvm, etc to build the application on the Core 2 Duo machine there is no crash.
I am also using homebrew: libmtp, libusb, libusb-compat, cryptopp, curl (with c-ares, openssl, nghttp2), boost. I have specified C++11 where necessary, and have specified --build-bottle. I am statically linking to these libraries.
I have tried to use otool -tV on all libraries, the final binary, etc to find SSE instructions.
I have tried to set the Xcode LLVM build setting "Enable Additional Vector Extensions" to "platform" and "SSE3" to no avail. This is probably because homebrew isn't passing the --universal flag from curl to the building of openssl and it's cryptlib.
I have taken static libraries libcurl.a (CURL), libssl.a (OpenSSL), libcrypto.a (OpenSSL), libz.a (zlib) from the older machine and added them to my repository. Using Xcode to link them into my application solves the problem.
Are there other tools I can should use to narrow down the offending instruction?
Are there other explanations for the crash?
Addendum:
In addition to building the libraries on an older machine, I have also created a proof of concept, minimal, instant crash program that reports a slightly different crash location, but demonstrates the issue:
On an i7 (new Apple computer with new Intel CPU), use homebrew to install:
brew install curl --with-c-ares --with-openssl
Then copy this source into file sse.cpp:
#define CURL_STATICLIB
#include <curl/curl.h>
int main(int argc, const char * argv[]) {
curl_global_init(CURL_GLOBAL_ALL);
return 0;
}
Compile it:
clang++ sse.cpp -c -arch x86_64 -I/usr/local/opt/curl/include
clang++ -o a.out sse.o /usr/local/opt/openssl/lib/libssl.a /usr/local/opt/openssl/lib/libcrypto.a /usr/local/opt/zlib/lib/libz.a /usr/local/opt/curl/lib/libcurl.a /usr/local/opt/c-ares/lib/libcares.a -stdlib=libc++ -framework LDAP
Now move to an older Apple computer with older Intel CPU, and crash it:
./a.out
Crash Report (compressed):
Process: a.out [569]
...
Code Type: X86-64 (Native)
Parent Process: bash [448]
Responsible: Terminal [339]
...
OS Version: Mac OS X 10.10.5 (14F27)
...
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 a.out 0x000000010dbdce3f ENGINE_new + 36
1 a.out 0x000000010dbe05e3 ENGINE_load_dynamic + 11
2 a.out 0x000000010dbdf04a ENGINE_load_builtin_engines + 24
3 a.out 0x000000010dc76b36 Curl_ossl_init + 14
4 a.out 0x000000010dc5c2a5 curl_global_init + 114
5 a.out 0x000000010db51d95 main + 37
6 libdyld.dylib 0x00007fff88b735c9 start + 1
Does your code work when you disable compiler optimizations? If not, how about trying an older version of Xcode? It could just be a compiler bug, though I'd hope not! If you can find a working compiler or set of compiler options to check against, you could use LLVM's bugpoint tool to isolate which file is being miscompiled.
The solution appears to involve using:
export HOMEBREW_BUILD_BOTTLE=1
export HOMEBREW_BOTTLE_ARCH=core2
When building the homebrew libraries. Using Intel XED I was able to check the emitted machine code for unsupported instructions:
xed_cmd="/usr/local/bin/xed"
ar -x libcurl.a
parts=(*.o)
for j in "${parts[#]}"; do
chipcheck=$(${xed_cmd} -i ${j} -chip-check ${chipToCheck})
chiperrors=$(echo "${chipcheck}" | grep "# Total Chip Check Errors")
if [[ "$chiperrors" != "# Total Chip Check Errors: 0" ]] ; then
echo ERROR ${libname} ${j} $chiperrors
fi
done
I have a Linux executable that seems to have been written in C++ using a GNU compiler, and in debug mode. I'd like to know if my conclusion is correct and what are my chances of decompiling it into something at least somewhat readable. Here's a few telltale snippets from the executable:
Snippet 1
</heap>
<malloc version="1">
nclears >= 3 Arena %d:
system bytes = %10u
in use bytes = %10u
Total (incl. mmap):
max mmap regions = %10u
Snippet 2
__gnu_cxx::__concurrence_lock_error
Snippet 3
ELF file ABI version invalid ◻ invalid ELF header ◻ ELF file OS ABI invalid
Snippet 4
GCC: (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5 ◻
GCC: (Ubuntu/Linaro 4.4.4-14ubuntu1) 4.4.5 20100909 (prerelease)
Snippet 5
_dl_debug_vdprintf pid >= 0 && sizeof (pid_t) <= 4
...
_dl_debug_initialize (0, args->nsid)->r_state == RT_CONSISTENT
The file is full of readable text like this (but most of it is still gibberish). I don't think you should find this kind of text in an executable compiled in release mode (then again, my knowledge on the matter is very limited). What decompiler should I try to use on this executable?
why dont you put a breakpoint in main and run the executable??? if it is debug mode, you could see the full source code(if the source file is present in the same path). you could step in each step and see the function calls with exact arguments.
I have a C++ routine that I would like to pack in a Simulink S-Function. This C++ routines calls other routines that are in several other C++ files.
I could manage to have everything compiled (i.e. the mexglx file is generated) using the legacy_code tool. However, the following warning is issued:
Warning: You are using gcc version "4.4.4-14ubuntu5)". The earliest gcc version
supported with mex is "4.1". The latest version tested for use with mex
is "4.2". To download a different version of gcc, visit http://gcc.gnu.org
The problem arises when I try to generate the S-Function block by issuing the command:
legacy_code('slblock_generate', def);
At this point, the following error mentioning the GLIBCXX version is raised:
??? Error using ==> iAddSfunctionBlock at 183
Error due to multiple causes.
Error in ==>
/opt/matlab/toolbox/simulink/simulink/+legacycode/#LCT/generateslblock.p>
generateslblock at 55
Error in ==> /opt/matlab/toolbox/simulink/simulink/legacy_code.p>legacy_code at
160
Caused by:
Error using ==> iAddSfunctionBlock at 183
Invalid MEX-file 'sfun_vectorRotation_b.mexglx':
/opt/matlab/bin/glnx86/../../sys/os/glnx86/libstdc++.so.6: version
`GLIBCXX_3.4.11' not found (required by sfun_vectorRotation_b.mexglx).
Error using ==> iAddSfunctionBlock at 183
Error while obtaining sizes from MEX S-function 'sfun_vectorRotation_b' in
'untitled1/sfun_vectorRotation_b'. MATLAB error message:
Invalid MEX-file 'sfun_vectorRotation_b.mexglx':
/opt/matlab/bin/glnx86/../../sys/os/glnx86/libstdc++.so.6: version
`GLIBCXX_3.4.11' not found (required by sfun_vectorRotation_b.mexglx).
Honestly I am a bit lost at this point. I do not know if downgrading the g++ compilator would be enough or if I have to do some other things. Do you have a possible solution for this issue?
I am using Matlab 2009b in an Ubuntu 10.10 OS, and the g++ version is:
g++ (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
Thanks a lot in advance
Miquel
Finally I could solve the problem myself. Just download and install (via ./configure, make and make install) a supported version of gcc (anyone between 4.1 and 4.2 will do). In my case I tried gcc-4.2 and it works fine.
Thanks anyway!
Miquel