Skip navigation
Currently Being Moderated

llvm(?) error while compiling to swc

Aug 30, 2011 6:53 AM

I'm trying to build a project using OpenCV with alchemy (that's a tough topic, I know). My idea was to isolate the parts I need from OpenCV (v.2.2), comile them with alchemy g++ and link with my code statically. So here's what I do:


I have several parts of openCV 2.2 (core, imgproc) built file by file with the following string:

alc-on; for src in *.cpp ; do g++ -I../../include -DOSX -c -Wall -O3 -o ${PWD##*/}_`basename $src .cpp`.o $src ; done ; mv -v *.o ~/dev/cut/obj/

(Basically, I compile all the needed parts file-by-file and copy the resulting .o's into a specific folder)


After that, I take a simple OpenCV test file with the following contents:

#include <opencv/cv.h>
#include "AS3.h"

void testCV()
  cv::Mat a(3,3,CV_8UC1,cv::Scalar(1.0));
  cv::Mat b(3,3,CV_8UC1,cv::Scalar(2.0));
  cv::Mat c;

static AS3_Val test(void* self, AS3_Val args)
  return 0;

int main()
  AS3_Val testMethod = AS3_Function(NULL,test);
  AS3_Val result = AS3_Object("test: AS3ValType",testMethod);


  return 0;


And when I try to link it against all the *.o I have (assuming they are in the same folder):

g++ -I../include -Wall -O3 -DOSX -swc test_cv.cpp *.o -o cvtest.swc


I get the following error report:

WARNING: While resolving call to function 'main' arguments were dropped!
WARNING: While resolving call to function 'stub_null' arguments were dropped!
WARNING: While resolving call to function 'stub_zero' arguments were dropped!
WARNING: While resolving call to function 'stub_zero' arguments were dropped!
WARNING: While resolving call to function 'stub_zero' arguments were dropped!
WARNING: While resolving call to function 'stub_zero' arguments were dropped!
WARNING: While resolving call to function 'stub_zero' arguments were dropped!
Assertion failed: (TLI.isTypeLegal(VT) && "Intrinsic uses a non-legal type?"), function visitTargetIntrinsic, file /Volumes/data/dev/FlaCC/llvm-2.1/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp, line 2465.
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                   0x9125e05b _sigtramp + 43
3   ???                                 0xffffffff 0x0 + 4294967295
4   libSystem.B.dylib                   0x912eb5a5 raise + 26
5   libSystem.B.dylib                   0x913016e4 abort + 93
6   libSystem.B.dylib                   0x912ee20f __assert_rtn + 252
7   llc                                 0x003f3e2a _ZN4llvm11StoreSDNodeD1Ev + 90026
8   llc                                 0x003f5256 _ZN4llvm11StoreSDNodeD1Ev + 95190
9   llc                                 0x003f817c _ZN4llvm11StoreSDNodeD1Ev + 107260
10  llc                                 0x0040bc68 _ZN4llvm11StoreSDNodeD1Ev + 187880
11  llc                                 0x0040d3f2 _ZN4llvm11StoreSDNodeD1Ev + 193906
12  llc                                 0x0040f92e _ZN4llvm11StoreSDNodeD1Ev + 203438
13  llc                                 0x005d1926 _ZN4llvm12FunctionPassD1Ev + 20998
14  llc                                 0x005d1f3a _ZN4llvm12FunctionPassD1Ev + 22554
15  llc                                 0x005d20c5 _ZN4llvm12FunctionPassD1Ev + 22949
16  llc                                 0x00002e44 0x0 + 11844
17  llc                                 0x00001f36 0x0 + 7990
18  ???                                 0x00000006 0x0 + 6


Can anybody explain what is it all about and where should I look to fix it somehow?

  • Currently Being Moderated
    Jan 11, 2012 8:11 AM   in reply to bonext

    Did you finally succeed ?


    I'm trying to compile from your github repository on cygwin (windows).

    I achieved to compile each C++ and C sources from opencv / zlib / lapack (without DOSX option)


    Now i'm stuck at compiling the C++ wrapper from the flash folder as it seems the llvm fails resulting in a llvm-ld.stackdump file

    I tried with and without core_system.o as stated in readme with same result.


    I don't see any "SSE_2" in core/arithm.cpp but a grep command shows there are lots of "CV_SSE2" in mathfuncs.cpp

    Mark as:
  • Currently Being Moderated
    Jan 12, 2012 12:18 AM   in reply to bonext

    OK thank you for your answer.

    I'll try to investigate further, following your advices, or maybe ask for some help of C/C++ coders coworkers...


    If i succeed in any way, i'll try to document the process.

    Mark as:
  • Currently Being Moderated
    Jan 12, 2012 6:11 AM   in reply to Eric Helier

    I got some success at this time : achieved to compile and run the AS3 Sample from your repository (converting webcam frames to grayscale)


    I used ar to find where the llvm problem come from and found that the lapack/slas*.cpp are in cause.

    Simply excluding all theses + core/system.cpp from compilation it works


    I also used ar llvm archiver to compile first an archive library from all .o files


    Right now i'm trying to setup a simple face detection test...

    Mark as:
  • Currently Being Moderated
    Jan 16, 2012 12:34 AM   in reply to bonext



    About FaceDetection, at this time, i'm stuck at loading HaarCascades xml files. A coworker gave me his working version, but he works with opencv2.0, so it doesn't seem correct. And the supplyFile method of alchemy doesn't seem to work with HaarCascade.load from opencv...

    I spend some time testing image processing methods, like medianblur, flip, etc. (didn't achieve to make work methods like GaussianBlur that needs some "border data" (?) on the source image.


    I found that in the sample code on your repo, width and height of the frame (corresponding to rows and cols in opencv) where inverted, and that the color space of Flash frame is actually ARGB, and not RGBA.

    I also tried not to pass the ByteArray from flash to C and C to flash, but using returned pointer to read/write directly to memory. But that didn't change a lot about performances. MedianBlur on 640x480 gives me a 3fps rate. I will try to compare with native execution performances.

    Mark as:
  • Currently Being Moderated
    Jan 19, 2012 12:17 AM   in reply to bonext

    Yes it seems it is not as simple as using supplyFile...

    I tried with a static cpp version of haarcascade xml that a coworker gave me, but they work with opencv2.0. So at this time i started back compiling opencv2.0...

    ./configure didn"t work because of the "adl stuck" bug so i took the same way as yours with opencv2.2, compiling every .cpp to .*and so on.


    I know have a working opencv2.0.swc... let's hope i achieve to make a basic facedetection working sample today...


    For the medianblur comparison with native c application here are my results : (sigh)

    - Alchemy OpenCV (lapack) : ~400ms

    - C OpenCV (IPP) : ~10ms


    I begin to think that it won't be possible to get realtime tracking simply porting opencv with alchemy...

    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points