llvm dev - May 2013 - [LLVMdev] Shared library support of llvm

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>