Building LLVM as a shared library on MinGw (Makefiles)

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

Building LLVM as a shared library on MinGw (Makefiles)

Keno Fischer-2
The sed invocation in tools/llvm-shlib is stripping leading
underscores from symbols. This was breaking the windows dll build on
MinGw for me but I figure since it was in there it must work for
somebody. I'd like to figure out which configurations need the
underscore stripped and which don't. Is there anybody else building
DLLs under MinGw?

Thanks,
Keno
_______________________________________________
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: Building LLVM as a shared library on MinGw (Makefiles)

Reid Kleckner-2
I didn't think it was possible to build an LLVM DLL on Windows, but maybe I'm wrong.


On Thu, Jul 31, 2014 at 11:31 PM, Keno Fischer <[hidden email]> wrote:
The sed invocation in tools/llvm-shlib is stripping leading
underscores from symbols. This was breaking the windows dll build on
MinGw for me but I figure since it was in there it must work for
somebody. I'd like to figure out which configurations need the
underscore stripped and which don't. Is there anybody else building
DLLs under MinGw?

Thanks,
Keno
_______________________________________________
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: Building LLVM as a shared library on MinGw (Makefiles)

Ivan Garramona
The shared library works fine here. I only made one modification to the 'tools/llvm-shlib/Makefile', because otherwise, two shared libraries would be created.

I've commented out the line 'SHARED_ALIAS := 1' from the Makefile.

Here is the command line i used to build LLVM/Clang:
../../configure --build=i686-w64-mingw32 --disable-assertions --enable-keep-symbols --enable-optimized --enable-shared --enable-targets=x86,x86_64

I used Mingw-w64 4.9.1 i686 posix + Clang r213454.

Sorry for my English.

_______________________________________________
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: Building LLVM as a shared library on MinGw (Makefiles)

Keno Fischer-2
Hmm, that's intersting. I guess the difference might be that you're
targetting 32bit and I'm targetting 64bit. Does it still work if you
replace
"s/^.* T _\([^.][^.]*\)$$/\1/p"
by
"s/^.* T \([^.][^.]*\)$$/\1/p"
in
tools/llvm-shlib (and similarly on the next line). If so I'll submit
this as a patch, if not I'll see how we can distinguish the two cases.

On Fri, Aug 1, 2014 at 3:01 PM, Ivan Garramona
<[hidden email]> wrote:

> The shared library works fine here. I only made one modification to the
> 'tools/llvm-shlib/Makefile', because otherwise, two shared libraries would
> be created.
>
> I've commented out the line 'SHARED_ALIAS := 1' from the Makefile.
>
> Here is the command line i used to build LLVM/Clang:
> ../../configure --build=i686-w64-mingw32 --disable-assertions
> --enable-keep-symbols --enable-optimized --enable-shared
> --enable-targets=x86,x86_64
>
> I used Mingw-w64 4.9.1 i686 posix + Clang r213454.
>
> Sorry for my English.
_______________________________________________
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: Building LLVM as a shared library on MinGw (Makefiles)

Ivan Garramona
2014-08-01 16:51 GMT-03:00 Keno Fischer <[hidden email]>:
Hmm, that's intersting. I guess the difference might be that you're
targetting 32bit and I'm targetting 64bit. Does it still work if you
replace
"s/^.* T _\([^.][^.]*\)$$/\1/p"
by
"s/^.* T \([^.][^.]*\)$$/\1/p"
in
tools/llvm-shlib (and similarly on the next line). If so I'll submit
this as a patch, if not I'll see how we can distinguish the two cases.

It does work.

_______________________________________________
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: Building LLVM as a shared library on MinGw (Makefiles)

Keno Fischer-2
Did you recompile completely? I just want to make sure you don't have
any stale state.

On Fri, Aug 1, 2014 at 4:25 PM, Ivan Garramona
<[hidden email]> wrote:

> 2014-08-01 16:51 GMT-03:00 Keno Fischer <[hidden email]>:
>
>> Hmm, that's intersting. I guess the difference might be that you're
>> targetting 32bit and I'm targetting 64bit. Does it still work if you
>> replace
>> "s/^.* T _\([^.][^.]*\)$$/\1/p"
>> by
>> "s/^.* T \([^.][^.]*\)$$/\1/p"
>> in
>> tools/llvm-shlib (and similarly on the next line). If so I'll submit
>> this as a patch, if not I'll see how we can distinguish the two cases.
>
>
> It does work.
_______________________________________________
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: Building LLVM as a shared library on MinGw (Makefiles)

Ivan Garramona
Sorry, i forgot to remove the '.export' file, and it weren't regenerated. It doesn't work after all. Before the modification (to the Makefile), the symbols had only one underscore, after the modification, they had two underscores.

I'll try to build 64bit version, and let you know the results.

_______________________________________________
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: Building LLVM as a shared library on MinGw (Makefiles)

Keno Fischer-2
Ok, this difference then comes down to the fact that the 32bit ABI
specifies leading underscores while the 64bit one does not. I'll
submit a patch.

On Fri, Aug 1, 2014 at 4:47 PM, Ivan Garramona
<[hidden email]> wrote:
> Sorry, i forgot to remove the '.export' file, and it weren't regenerated. It
> doesn't work after all. Before the modification (to the Makefile), the
> symbols had only one underscore, after the modification, they had two
> underscores.
>
> I'll try to build 64bit version, and let you know the results.
_______________________________________________
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: Building LLVM as a shared library on MinGw (Makefiles)

Óscar Fuentes
In reply to this post by Reid Kleckner-2
Reid Kleckner <[hidden email]> writes:

> I didn't think it was possible to build an LLVM DLL on Windows, but maybe
> I'm wrong.

It is fairly easy with MinGW because gcc/ld can auto-(export/import) the
symbols. It is not as robust as explicitly declaring the visible symbols
(as VS requires) but it used to work well enough for creating an usable
monolithic LLVM.dll.

_______________________________________________
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: Building LLVM as a shared library on MinGw (Makefiles)

Yaron Keren
While MinGW can auto-export public symbols of a DLL, I'd try to avoid this approach since MinGW auto-exports ALL public symbols. For a large project such as LLVM it may result in 10,000 or 100,000 exports instead of the 1000 actually required.

Yaron



2014-08-02 1:25 GMT+03:00 Óscar Fuentes <[hidden email]>:
Reid Kleckner <[hidden email]> writes:

> I didn't think it was possible to build an LLVM DLL on Windows, but maybe
> I'm wrong.

It is fairly easy with MinGW because gcc/ld can auto-(export/import) the
symbols. It is not as robust as explicitly declaring the visible symbols
(as VS requires) but it used to work well enough for creating an usable
monolithic LLVM.dll.

_______________________________________________
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