locked
Redistributing static libraries? RRS feed

  • Question

  • I have a static library which is currently available on Win32, Win64, Mac OSX and Linux.

    However I'm interested in a qualified opinion if it's realistic to create static libraries on Windows CE?

    My library is written in C++ but exports a C frontend. However I'm in doubt. There exist atleast 4 different processor types (x86, mips, sh and arm) and on top of that lots of different SDKs. I mostly only use CRT functions, STL and a few Windows specific functions but I sense I could be in big trouble as far as compatibility goes.

    As I found out (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=111412&SiteID=1), there are problems when mixing SDK's. However I guess this is nessecary if I want to support Pocket PC, Windows Mobile, generic Windows CE and all the other SDK variations which I don't even know about.

    I know if it's possible to work out if I would recompile my code to _all_ variations but given there are atleast 12 combinations (4 CPU types and atleast 3 platforms) it could be an increasing problem.

    I have to mention that the reason why I'm distributing static libraries are that they must be compiled into users binary files. The library has a undefined function which is written by user. I guess if I changed this function into a callback I could compile the code as a dll but I'd rather not if avoidable.

    What are your thoughts on this?

    Wednesday, November 23, 2005 8:56 AM

Answers

  • Static linking is sometimes is strongly suggested to prevent complex scenarios in Win CE ,
    Reason : the way dll is loaded in WinCE is different from that of a desktop , There is a possibility of a difficulty in servicing these dlls if not statically linked.
    static linked dlls, are easy to service, distribute and can also prevent potential dll hell. 

    Thanks
    Srikanth Bogadapati (Microsoft)  
    Friday, November 25, 2005 6:33 AM

All replies

  • Static linking is sometimes is strongly suggested to prevent complex scenarios in Win CE ,
    Reason : the way dll is loaded in WinCE is different from that of a desktop , There is a possibility of a difficulty in servicing these dlls if not statically linked.
    static linked dlls, are easy to service, distribute and can also prevent potential dll hell. 

    Thanks
    Srikanth Bogadapati (Microsoft)  
    Friday, November 25, 2005 6:33 AM
  • Hi Srikanth,

    Thank you for your answer. However it seems you did not take the time to read the question properly. I'm not discussing dll's or linked exe files but static libraries (*.lib files).

    I understand that there are lots of things to be aware of when releasing software under Windows CE.
    What I want is to make a library that my users can link into their CE application. I'm sure I am not the first one doing so, so I am asking about best practice to avoid potential problems that others probably already faced and solved.

    Since lots of different SDK's exist there could potentially be problems with CRT functions which are not binary compatible across the SDK's. This is something which I recently discovered between different releases of Win32/Win64 CRT so I assume the same thing goes on under CE.

    Thanks in advance.

    -- Henrik
    Sunday, November 27, 2005 7:53 PM
  • Actually we use VC++ 6.0. For the static libraries that we make we compile specifically for each version of Visual Studio. This means that we perform seperate builds for around 4 versions of VS. Very painful and timeconsuming.

    However there are ways to overcome the problems. I've spent lots of research on it and found what we specifically can do to make 1 build. There are still potential problems which I didn't research and this is the reason we're not doing this already.

    Basicly avoid STL from Microsoft. If you use STL then use something like STLPort instead. The reason is that some functions are found in the CRT libraries and thus are different between each version of VS (since STL itself is different for each version).

    This problem is because there are bindings to C++ functions present in the CRT.

    Avoid some of the CRT functions like findfirst(). The interface has changed over time and is binary incompatible. The library will link without problems but the functions gives bad results. Instead you should use the Win32 api. There are probably more interfaces which has changed over time but I havn't been able to find a list of these functions.

    But theres alot more to it then just this. I think lots of CRT calls has to be removed in our code and replaced with Win32 functions. If Win32 functions are not available we would need to emulate the functionality by writing our own CRT functionality.

    As you can hear it is far from trivial and there are no guides in how to solve it in 5 minutes. I would recommend you to spend atleast 3 weeks on it and you'll discover the same things as me and eventually find another way of doing things.

    -- Henrik

    Monday, March 20, 2006 4:59 PM
  • Henrik,

    We have had problems with our libs on our projects. EVC libs and Visual Studio 2005 libs don't seem to play nicely together and so we end up servicing two builds. Although it is easier for our clients it is more difficult for us to maintain.

     

    Monday, March 20, 2006 9:07 PM