home Forums # Technical Support Linking against fuzzylite: undefined reference errors

Tagged: 

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #1972
    Unknown
    Member

    Hello all,
    I have read the posts regarding undefined reference linker errors but still did not find a solution.
    I tried to compile the example (http://fuzzylite.com/cpp) using gcc/i686-w64-mingw32/4.6.3 and link against fuzzylite (4.0). BTW, I do not get these errors when I use MS VisualStudio10.

    This is how the errors look like:

    D:\R_analysis\VC++_NVT\Fuzzy>make
    g++ -O1 -Wall -Ifuzzylite -c -o “main.o” “main.cpp”
    g++ -O1 -Wall -Lfuzzylite_CMake/bin/Release -o main main.o -lfuzzylite
    main.o:main.cpp:(.text+0xcb): undefined reference to `fl::Engine::Engine(std::string const&)’
    main.o:main.cpp:(.text+0x151): undefined reference to `fl::InputVariable::InputVariable(std::string const&, double, doub
    le)’
    ….
    collect2: ld returned 1 exit status
    make: *** [main] Error 1

    What did I do wrong?

    #1973
    Unknown
    Member

    Note: I get the same errors when linking against fuzzylite-5.0 (binary download).

    #1974

    Hi,

    I thought I had replied to this post before.

    Anyway, thank you for your question.

    Based on your errors, I think the system cannot find the fuzzylite library. Please, make sure the library is located in the given path. Some times, it is worth trying to compile against the static library instead of the dynamic library.

    Let me know if it works for you.

    Cheers.

    #1975
    Unknown
    Member

    I am sure, the system finds the fuzzylite library. If the path or libname is (willfully) wrong, I get as expected “ld.exe: cannot find -lfuzzylite”. Compiling against fuzzylite-static yielded the same errors.

    In this post http://fuzzylite.com/forums/topic/regarding-problem-running-example you argue about using the flag -DFL_USE_FLOAT. In my case, I did not build the fuzzylite 5.0 library – I just used the downloaded binary to link against. Still setting this flag (or not) in makefile does not make any difference.

    Somehow I expect that compiling the example on the start page (http://fuzzylite.com/cpp) SHOULD be easily possible using gcc/mingw under windows. Note, librt (-lrt) and especially the method clock_gettime() is not available for mingw (gcc/i686-w64-mingw32/4.6.3).

    Do you or your developers have a working code example/makefile for mingw32 ?
    Thanks.

    #1976

    Hi Egus,

    I am not aware of any working examples for mingw.

    My main issue with mingw and cygwin is that I really do not know if that is Windows or Linux or a weird mixture of the two.

    A problem could be that the Windows library available in Downloads page was built for 32bits, whereas the libraries for Linux are built for 64bits. Which one are you using (Windows or Linux)? If you were to compile fuzzylite under mingw or cygw, I do not know what would happen to the flags -DFL_WINDOWS and -DFL_UNIX which are automatically assigned in file fl/fuzzylite.h. Would the two be activated?

    As for the clock_gettime(), this has been moved to C++11 in fuzzylite-5.0. Perhaps you should try with fuzzylite-5.0.

    Out of curiosity, could you elaborate on why would you prefer to use mingw or cygwin instead of native Windows and Linux? Also, could you briefly tell me about the process of compiling in cygwin/mingw? In their respective terminals, are you building on Linux or Windows? Is the Windows compiler or linker involved in the cygwin/mingw process?

    Cheers,

    Juan.

    #1978
    Unknown
    Member

    Hi Juan,

    I finally got it working be recompiling fuzzylite (5.0) with the mingw-gcc compiler under Window 7.
    The fuzzylite sources can be compiled when build.bat and the CMakeLists.txt are slightly modified.

    build.bat:

    cmake .. -G"Unix Makefiles" -DCMAKE_BUILD_TYPE=Release -DFL_BACKTRACE=OFF -DFL_USE_FLOAT=OFF -DFL_CPP11=OFF -DCMAKE_CXX_COMPILER=C:/Programs/Rtools/gcc-4.6.3/bin/g++.exe
    make
    # instead of
    cmake .. -G"NMake Makefiles" -DCMAKE_BUILD_TYPE=Release -DFL_BACKTRACE=OFF -DFL_USE_FLOAT=OFF -DFL_CPP11=OFF
    nmake
    

    CMakeLists.txt:

    if(WIN32)
    	set(CMAKE_CXX_FLAGS "-pedantic -Wall -Wextra")
        	set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG}")
        	set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE}")
        	if(NOT APPLE)
            	set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--no-undefined")     
    	endif()
    ...
    
    # instead of
    
    if(WIN32)
    	set(CMAKE_CXX_FLAGS "/WX /W4 /EHsc")
    ...
    

    In fact, the compilation looks more like “Linux” which is due to different command line options of the compiler and make system used.
    Why do I prefer mingw-gcc? I want to use a compiler under windows which is compatible to many other platforms. Moreover, I am using the Rcpp framework (http://dirk.eddelbuettel.com/code/rcpp.html) to integrate c/c++ code with R using the gnu/gcc toolchain.

    BTW, this is how I compiled under Linux and Windows:

    
    # Linux
    egerm@bert:~/fuzzylite-5.0$ make
    g++  -O1 -Wall  -Isources/fuzzylite -c -o "main.o" "main.cpp"
    g++  -O1 -Wall  -Lsources/fuzzylite/release/bin -o main main.o -lfuzzylite
    
    # Windows:
    D:\Fuzzy\fuzzylite-5.0>make
    g++  -O1 -Wall  -Isources/fuzzylite -c -o "main.o" "main.cpp"
    g++  -O1 -Wall  -Lsources/fuzzylite/release/bin -o main main.o -lfuzzylite
    

    The main.cpp is identical to the code here: http://fuzzylite.com/cpp
    In both cases the makefile looks like this:

    PRG := main
    INC_DIR := -Isources/fuzzylite
    LIB_DIR := -Lsources/fuzzylite/release/bin
    LIBS := -lfuzzylite
    CXX := g++ 
    CXXFLAGS := -O1 -Wall 
    
    .PHONY: all 
    all: $(PRG) 
    
    $(PRG): main.o
    	$(CXX) $(CXXFLAGS) $(LIB_DIR) -o $(PRG) main.o $(LIBS)
    
    main.o: main.cpp 
    	$(CXX) $(CXXFLAGS) $(INC_DIR) -c -o "$@" "$<"
    

    Kind regards
    Egus

Viewing 6 posts - 1 through 6 (of 6 total)
  • You must be logged in to reply to this topic.