According to http://llvm.org/docs/CMake.html, "Shared libraries are not supported on Windows and not recommended in the other OSes". The problem is that static libraries have some limitations, especially when linked into multiple shared libraries, the global data of llvm could have multiple copies leading to undefined behaviors. This has caused much pains during my usage of llvm. My questions are: 1. What are the reasons to not support shared libraries on Windows and not recommended in other OSes? 2. Are there any plans to support shared libraries? Thanks very much for any information! Best, -Peng -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130508/51fbde66/attachment.html>
I've never tried building LLVM dlls on Windows, so this is all from faulty mailing list memory. You should be able to make a ginormous LLVM.dll that includes everything you need just once. This should avoid your duplicate data in depending DLLs problem. Someone else may know how to do this, or you can search the list. Splitting LLVM's internal libraries up into little dlls would speed up incremental builds, but it's not easy. There's no way to blanket export every symbol from a dll. Even if you did, I've heard there are issues with exporting more than 2^16 symbols. Adding targeted dllexport annotations won't work because non-Windows developers (the majority) shouldn't be burdened with keeping them up to date. On Wed, May 8, 2013 at 11:30 AM, Peng Cheng <gm4cheng at gmail.com> wrote:> According to http://llvm.org/docs/CMake.html, "Shared libraries are not > supported on Windows and not recommended in the other OSes". > > The problem is that static libraries have some limitations, especially when > linked into multiple shared libraries, the global data of llvm could have > multiple copies leading to undefined behaviors. This has caused much pains > during my usage of llvm. > > My questions are: > > 1. What are the reasons to not support shared libraries on Windows and not > recommended in other OSes? > > 2. Are there any plans to support shared libraries? > > Thanks very much for any information! > > Best, > -Peng > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Peng Cheng <gm4cheng at gmail.com> writes:> According to http://llvm.org/docs/CMake.html, "Shared libraries are not > supported on Windows and not recommended in the other OSes". > > The problem is that static libraries have some limitations, especially when > linked into multiple shared libraries, the global data of llvm could have > multiple copies leading to undefined behaviors. This has caused much pains > during my usage of llvm. > > My questions are: > > 1. What are the reasons to not support shared libraries on Windows and not > recommended in other OSes?IIRC shared libraries are not recommended on other OSes because people found that starting an executable that uses all those LLVM libraries is slow, which hurts a lot when running the test suite, so the developers tend to avoid shared libraries and they are not tested nor their specific requirements considered while developing LLVM. IIRC (again) long time ago I did some experimentation and running tests was about as fast whith using shared libraries as with static ones on a Linux machine. Windows with the MSVC++ compiler does not support shared libraries at all for the reasons given by Reid. For MinGW it is possible to create a monolithic DLL (I did just that long time ago) or maybe DLL versions of the static libraries. However, the caveats about being an untested configuration are even stronger than on the other OSes.> 2. Are there any plans to support shared libraries?No AFAIK.
Actually, adding a LLVM_EXPORT macro would be positive for other environments, because you can then build LLVM as a shared library with -fvisibility=hidden and use LLVM_EXPORT to only make public symbols visible. There are several advantages to this, as noted here: http://gcc.gnu.org/wiki/Visibility From: Reid Kleckner Sent: Wednesday, May 08, 2013 6:21 PM To: Peng Cheng Cc: LLVMdev at cs.uiuc.edu Subject: Re: [LLVMdev] Shared library support of llvm I've never tried building LLVM dlls on Windows, so this is all from faulty mailing list memory. You should be able to make a ginormous LLVM.dll that includes everything you need just once. This should avoid your duplicate data in depending DLLs problem. Someone else may know how to do this, or you can search the list. Splitting LLVM's internal libraries up into little dlls would speed up incremental builds, but it's not easy. There's no way to blanket export every symbol from a dll. Even if you did, I've heard there are issues with exporting more than 2^16 symbols. Adding targeted dllexport annotations won't work because non-Windows developers (the majority) shouldn't be burdened with keeping them up to date. On Wed, May 8, 2013 at 11:30 AM, Peng Cheng <gm4cheng at gmail.com> wrote:> According to http://llvm.org/docs/CMake.html, "Shared libraries are not > supported on Windows and not recommended in the other OSes". > > The problem is that static libraries have some limitations, especially > when > linked into multiple shared libraries, the global data of llvm could have > multiple copies leading to undefined behaviors. This has caused much > pains > during my usage of llvm. > > My questions are: > > 1. What are the reasons to not support shared libraries on Windows and not > recommended in other OSes? > > 2. Are there any plans to support shared libraries? > > Thanks very much for any information! > > Best, > -Peng > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >_______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hello, with some minor modifications I was able to build a DLL with Visual Studio 11, which contained most LLVM-C functions in one DLL. However, some manual work was necessary (e.g. build an export.def file), but beside this it was quite easy. Since Visual Studio isn't the IDE I'm used to, I can't tell exactly what I have done, but since I was able to build it first for version 3.2 and later for 3.3 it must have been quite simple. Just add dependencies to the static libraries you want to use and add those functions to a .def file you add in the projects settings. Other options are probably just sugar. Since I started with the solution, which was created by CMake it was only possible to do it either for 32-bit or 64-bit, but since I only needed 32-bit for now it's not a big issue. The mingw solution didn't work for me somehow. Especially the DLL was too big (22 MB), when I needed only some features (custom DLL is just 7 MB). -- Christian-W. Budde Eleonorenstr. 17 30449 Hannover Tel.: +49 511 31048857 E-Mail: Christian at savioursofsoul.de WWW: http://www.savioursofsoul.de/Christian
On Wed, May 8, 2013 at 8:55 PM, Morten Ofstad <morten at hue.no> wrote:> Actually, adding a LLVM_EXPORT macro would be positive for other > environments, because you can then build LLVM > as a shared library with -fvisibility=hidden and use LLVM_EXPORT to only > make public symbols visible. There are several > advantages to this, as noted here: >I agree, this would be useful even for other environments to solve the bloat that can happen by exporting all the symbols. Adding targeted dllexport annotations won't work because non-Windows developers (the majority) shouldn't be burdened with keeping them up to date. On Wed, May 8, 2013 at 5:21 PM, Reid Kleckner <rnk at google.com> wrote:> Adding targeted dllexport annotations won't work because non-Windows > developers (the majority) shouldn't be burdened with keeping them up > to date. >IMHO it's not that big of a burden, we have build bots that can signal whatever problems come up. And it would also be useful for other platforms. -- João Matos -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130508/a46bb44d/attachment.html>