#84 Compile IT++ library as shared library on Windows

Next_Release
closed
itpp (51)
3
2014-07-16
2012-09-11
No

Currently on Windows IT++ is compiled only as static library. In order to reduce executable size IT++ should be compiled also as shared library. This implies that some changes need to be made in the code when MSVC compiler is detected to export IT++ symbols. This should be a feature supported only by cmake build system.

Discussion

1 2 > >> (Page 1 of 2)
  • Bogdan Cristea

    Bogdan Cristea - 2013-01-21

    A header file, itexports.h, has been added that defines the compiler variable ITPP_EXPORT allowing to import/export IT++ library symbols with Visual Studio C++. This header file and the associated compiler variable need to be used in IT++ library in order to import/export library symbols.

     
  • Bogdan Cristea

    Bogdan Cristea - 2013-01-21
    • status: open --> accepted
    • assigned_to: Bogdan Cristea
     
  • andy_panov

    andy_panov - 2013-01-22

    Hi Bogdan,

    I am experimenting with shared build on windows trying to export Vec template and related operators and functions. Right now i am sorting out the issue with templated friends of Vec class - MSVC complains if some explicit instantiations of, say, dot product are declared with declspec(dllexport) while others are not. I'll be posting the modified vec.h, vec.cpp when I get done with it.

    Andy

     
  • andy_panov

    andy_panov - 2013-01-22

    Bogdan,

    I've managed to export the templates from vec.h/vec.cpp both for shared-static builds on msvc. Here are the modified files. Could you please verify that it does not break GCC builds? If so, we can proceed and change the rest of the files the same way.

    Andy

     
  • andy_panov

    andy_panov - 2013-01-22

    Oops, forgot to attach itppexports.h.cmake

     
  • Bogdan Cristea

    Bogdan Cristea - 2013-01-23

    Hi
    I have committed into trunk itexports.h.cmake. Please let me know it that suits you. Good job Andy.
    regards
    Bogdan

     
  • andy_panov

    andy_panov - 2013-01-24

    Hi, Bogdan

    So far I am OK with the itexports.h.cmake. The most serious issues I've encountered while trying to make things exportable from shared lib are related to the dependencies from STL templates. Some classes (see binfile.h for example) just inherit from std streams. Others include STL strings and streams as data members. All these classes should be reworked to hide implementation details using pimpl idiom (Microsoft does not provide the reliable way to export such things and rearchitecture is the only option). It will result in more obscure and error-prone implementation. I've started to doubt if this endevour worth the efforts :-(.

    The other way around is to hide such classes in the shared builds and reduce the functionality of the shared lib.

    Andy

     
  • Bogdan Cristea

    Bogdan Cristea - 2013-01-25

    Hi Andy

    Please met me know if I can help. There is no need to refactor too much, rather to try to hide these classes and see if it makes sense to compile such shared library.

    regards
    Bogdan

     
  • andy_panov

    andy_panov - 2013-01-26

    Hi Bogdan

    Please find patch file with results. Also I've attached whole content of my itpp folder just in case I missed something while making a patch.

    Gtests and old tests passed on windows with acml (it_file test is the only exception - see below).

    Not sure you'll be happy with the result - I had to modify almost all files in the itpp folder :-). I tried not to refactor much, but still made several changes to make classes exportable. Here is the list of things I was unable to export (the stuff is still used inside the shared lib but class definitions are not exported and can not be used in user's code):
    -binfile, itfile classes (Aggregate fstream, Inherit from fstream)
    -audiofile class (Aggregates fstream)
    -all contents of protocol folder (needs heavy refactoring, lots of inheritance from STL containers, key classes aggregate STL containers and strings)

    I've added some guards in headers to let user know that definitions are not available on windows while linking with shared library.

    best regards,
    Andy.

     
  • Bogdan Cristea

    Bogdan Cristea - 2013-02-02

    Hi Andy

    I have attached a pdf file with my observations. The main problem I have found is that your patch contains several patches. I would like to have a single patch only for compiling IT++ as shared library on Windows. This is also needed since some classes cannot be exported and I would like to rewrite them or provide some interface. For all the other proposed corrections (e.g. EXIT class) please prepare separate patches.

    regards
    Bogdan

     
  • andy_panov

    andy_panov - 2013-02-05

    Hi Bogdan,

    Unfortunately the most refactoring is related to exporting activity. I would prefer not to touch working code but I was unable to export important stuff without it. What I really forgot is to exclude Exit patch - I was using the modified library for a while and did not noticed the unrelated changes while doing the patch. Please find attached file with my comments and explanations. I hope it become more clear why I did some modifications.

    Please do not hesitate to contact me if you have any further questions. I think, we should finalize this thing in order to move forward.

    Andy

     
  • Bogdan Cristea

    Bogdan Cristea - 2013-03-10

    Hi Andy
    I have merged into trunk the patch you proposed (I have changed or restored some things). Please have a look and tell me if everything is ok. The following classes are not exported, so I'll let this feature still open:
    - audiofile
    - gf2mat
    - binfile
    - itfile (this must be a priority as IMHO is one of the central features of IT++)
    - packet_generator
    - signals_slots
    - front_drop_queue
    - tcp_client_server
    - packet
    - selective_repeat
    - tcp
    - events
    - packet_channel

     
  • andy_panov

    andy_panov - 2013-03-11

    Hi Bogdan,

    I've tested shared and static library builds on MSVC. I've found some minor issues during testing and prepared a small patch with fixes.

    Following is the list of fixed things:

    1)filter.h - I've restored my patch for AR_Filter class to fix following warning:
    D:/Development/itpp/itpp_trunk\itpp/signal/filter.h(177): warning C4251: 'itpp::AR_Filter<T1,T2,T3>::a0' : class 'std::complex<double>' needs to have dll-interface to be used by clients of class 'itpp::AR_Filter<T1,T2,T3>'
    2> with
    2>
    2> T1=double,
    2> T2=std::complex<double>,
    2> T3=std::complex<double>
    2>


    2> C:\Program Files\Microsoft Visual Studio 10.0\VC\include\complex(668) : see declaration of 'std::complex<double>'
    2> D:/Development/itpp/itpp_trunk\itpp/signal/filter.h(582) : see reference to class template instantiation 'itpp::AR_Filter<T1,T2,T3>' being compiled
    2> with
    2> [
    2> T1=double,
    2> T2=std::complex<double>,
    2> T3=std::complex<double>

    2)Code repetition in itexports.h.cmake
    ....

    elif (GNUC >= 4) /UNIX/

    #ifndef ITPP_EXPORT_TEMPLATE
    #define ITPP_EXPORT_TEMPLATE extern
    #endif
    #ifndef ITPP_EXPORT_TEMPLATE
    #define ITPP_EXPORT_TEMPLATE extern
    #endif

    endif

    ....

    3)gf2mat.h ifdef conditions fixed, MSVC static librarty build is broken otherwise with
    2>....\itpp_trunk\itpp\base\gf2mat.cpp(1036): error C2248: 'itpp::GF2mat::nrows' : cannot access private member declared in class 'itpp::GF2mat'

    PS It is not so critical, but I would still suggest to conditionally instantiate templates in library headers to reduce compilation times
    and to get rid of the warnings during the static build:
    2>interleave.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
    2>svec.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
    2>smat.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
    2>help_functions.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library

    PPS I will look into the it_file thing and try to make it exportable. I'll publish a patch here once I'll be done with it.

    Best Regards,
    Andy

     
  • Bogdan Cristea

    Bogdan Cristea - 2013-03-12

    Hi

    Thank you for your feedback. The patch you propose for filter.h is not correct as this will change the behavior of the AR_filter class as in set_coeff method we need to normalize the coefficients to the first coefficient so that the first coeff. is one after normalization. I have used another Vec<T2> data member to keep the first coeff for future reuse. Otherwise everything looks ok on my side, thank you for the big help with this feature.
    For optimizing the compilation times and warning removal, please open a bug report.

    regards
    Bogdan

     
    • andy_panov

      andy_panov - 2013-03-12

      Hi Bogdan,

      I've completely forgot about getter while doing the patch :-(. Thank you very much for pointing this out.

      I gonna open a bug report regarding the template instantiation right now but provide a patch a bit later once I'll sort out the it_file issue.

      Andy.

       
  • andy_panov

    andy_panov - 2013-03-29

    Hi Bogdan,

    Please find attached patch solving the exportability of it_file.h definitions. Also, it enables Gf2mat inserter/extractor to/from it_file for the shared builds and provides it_file test case for gtest framework.

    Aside from the main goal I noticed and fixed the following issues:

    1.There was an issue in it_file implementation - itpp::bin types were read/written using extraction/insertion operators defined for standard streams, since binfile was inherited from std::fstream. These operators do not take binary stream endianness into account. I've implemented additional extractor and inserter for binary stream to store/extract itpp::bin data.

    2.CmakeLists.txt problem in gtest folder. For whatever reason set_target_properties() did not add ALL required preprocessor definitions. Only the first listed define was added. I've implemented the source file specific options as it was done in CmakeLists.txt in tests folder.

    3.Some of the import declarations are not visible by compiler when user includes itbase.h and builds application against dynamic library. Mostly it is related to some Array, Vector and Mat containers explicitly instantiated in library headers from comm folder. While building the application compiler generates the missing definitions since it does not see _dllimport attribute set in headers which were not included.
    This results in linker errors while building the application (linker complains on multiply defined symbols). In order to resolve this I've introduced itpp/base/base_exports.h where I've included all the specializations used in other parts of the library. The goal was two-fold: firstly, it allowed me to get rid of some ugly ifdefs in library headers, secondly - explicitly instantiated templates became visible with _dllimport attribute when /itpp/itbase.h is included in user's app.

    Andy.

     
  • Bogdan Cristea

    Bogdan Cristea - 2013-04-01

    Hi Andy
    Your patch looks ok, but it seems that the tests using Google framework don't compile with the following error:

    36>itpp.lib(itpp.dll) : error LNK2005: "public: class itpp::Vec<int> & cdecl itpp::Array<class itpp::Vec<int=""> >::operator()(int)" (??R?$Array@V?$Vec@H@itpp@@@itpp@@QEAAAEAV?$Vec@H@1@H@Z) already defined in itfile_test.obj
    36>itpp.lib(itpp.dll) : error LNK2005: "public: virtual
    cdecl itpp::Array<class itpp::Vec<int=""> >::~Array<class itpp::Vec<int=""> >(void)" (??1?$Array@V?$Vec@H@itpp@@@itpp@@UEAA@XZ) already defined in itfile_test.obj
    36>itpp.lib(itpp.dll) : error LNK2005: "public: void cdecl itpp::Array<class itpp::Vec<int=""> >::set_size(int,bool)" (?set_size@?$Array@V?$Vec@H@itpp@@@itpp@@QEAAXH_N@Z) already defined in itfile_test.obj
    36>itpp.lib(itpp.dll) : error LNK2005: "public:
    cdecl itpp::Array<class itpp::Vec<int=""> >::Array<class itpp::Vec<int=""> >(class itpp::Factory const &)" (??0?$Array@V?$Vec@H@itpp@@@itpp@@QEAA@AEBVFactory@1@@Z) already defined in itfile_test.obj
    36>C:\Users\Bogdan Cristea\Documents\C++\trunk_git\build\gtests\Debug\itpp_gtests.exe : fatal error LNK1169: one or more multiply defined symbols found

     
  • andy_panov

    andy_panov - 2013-04-01

    Pleas add the following line to itbase.h:

    include <itpp base="" base_exports.h="">

    This should fix the problem.

    Andy

     
  • andy_panov

    andy_panov - 2013-04-01

    Sorry... ugly sourceforge formatting...

    ~~~~~~~~~

    include <itpp base="" base_exports.h="">

    ~~~~~~~~~~

     
  • Bogdan Cristea

    Bogdan Cristea - 2013-04-01

    Thanks for the quick reply. I would put this include in a public header, e.g. itbase.h and try to hide somehow base_exports.h. I'll try this on my side.

     
  • Bogdan Cristea

    Bogdan Cristea - 2013-04-01

    Also it will avoid to install base_exports.h

     
  • andy_panov

    andy_panov - 2013-04-01

    I had an idea to put these definitions into it_exports.h but they depend on several headers in base folder. It would be nice if you devise the smart way to hide this stuff (or, make cmake to generate appropriate definitions in place). I am not so strong in all these things.

    Thank you.
    Andy

     
  • Bogdan Cristea

    Bogdan Cristea - 2013-04-02

    Hi Andy
    I have committed your patch with some minor changes (base_exports.h is in itbase.h). Please let me know if you find any issues on your side.
    regards
    Bogdan

     
  • andy_panov

    andy_panov - 2013-04-02

    I've just finished testing on msvc+acml. Tried both new and old style tests with static and shared build and found no regression.

    I've opened a new discussion thread hoping to collect some feedback regarding audio file classes refactoring from interested people. That would be the next thing I am planning to do.

    Andy.

     
  • andy_panov

    andy_panov - 2013-04-02

    PS I've noticed, you do not want to have a c++11 extensions in the codebase. Should
    I restrict myself with c++98/03 while suggesting changes?

     
1 2 > >> (Page 1 of 2)

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks