Shared library support of llvm

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Shared library support of llvm

Peng Cheng
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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Shared library support of llvm

Reid Kleckner-2
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 <[hidden email]> 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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Shared library support of llvm

Óscar Fuentes
In reply to this post by Peng Cheng
Peng Cheng <[hidden email]> 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.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Shared library support of llvm

Morten Ofstad
In reply to this post by Reid Kleckner-2
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: [hidden email]
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 <[hidden email]> 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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev 

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Shared library support of llvm

Christian Budde
In reply to this post by Peng Cheng
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: [hidden email]
WWW: http://www.savioursofsoul.de/Christian

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Shared library support of llvm

João Matos
In reply to this post by Morten Ofstad
On Wed, May 8, 2013 at 8:55 PM, Morten Ofstad <[hidden email]> 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 <[hidden email]> 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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Shared library support of llvm

Reid Kleckner-2
On Wed, May 8, 2013 at 6:04 PM, João Matos <[hidden email]> wrote:
> On Wed, May 8, 2013 at 5:21 PM, Reid Kleckner <[hidden email]> 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.

Maybe it just needs selling.  If we can make the case that the
annotations cut down the time to run the test suite with the shared
library build, then maybe people will think it's worth the hassle.  :)

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev