[cfe-dev] Clang 3.5 Release Pre-Pre-Pre-Announcement

[Nico Weber]

On Sun, May 18, 2014 at 1:34 PM, Alp Toker <alp at nuanti.com> wrote:

>
> On 16/05/2014 22:36, Reid Kleckner wrote:
>
>> On Fri, May 16, 2014 at 11:49 AM, Alp Toker <alp at nuanti.com <mailto:
>> alp at nuanti.com>> wrote:
>>
>>
>>     On 16/05/2014 21:20, Richard wrote:
>>
>>         In article <4FBFE344-19A4-4A9A-9C93-AB9A4554D6CE at gmail.com
>>         <mailto:4FBFE344-19A4-4A9A-9C93-AB9A4554D6CE at gmail.com>>,
>>              Bill Wendling <isanbard at gmail.com
>>
>>         <mailto:isanbard at gmail.com>> writes:
>>
>>             Have you been sleeping poorly worried about the Clang 3.5
>>             release? Well,
>>             this may help! The plan right now is to start testing in
>>             July with August
>>             as the target release month. There isn't a schedule yet,
>>             of course. But it
>>             should be a goodly amount of time for all y'all to prepare
>>             for the release
>>             process.
>>
>>             If you have any questions, please let me know. If you'd
>>             like to volunteer
>>             to be a tester, also let me know. :-)
>>
>>         I have some packaging changes I'd like to see in place for the 3.5
>>         packaging.  The changes include some more utilities in the
>>         package for
>>         refactoring tool developers and there is an issue with the way the
>>         Windows packages are being built that causes them to omit many
>>         of the
>>         things in the unix packages.  Again, this is to make it easier to
>>         write refactoring tools.
>>
>>
>>     So far the idea with the Windows installer has been to provide a
>>     toolchain rather than a complete SDK, but it'd be nice to see if
>>     we can head in that direction, perhaps with a separate SDK package.
>>
>>     CC'ing in Hans who has opinions on this.
>>
>>     Which files did you want to include specifically?
>>
>>
>> Initially I didn't want to do this because it bloats the installation.
>>  The package itself is compressed, so a lot of the code duplication is
>> mitigated.
>>
>> Normally people solve this with shared libraries, and I assumed that's
>> what we did on Linux, where we have a shared library build.  Turns out I
>> was wrong, our pre-built binaries are totally static.  So maybe this
>> doesn't matter as much as I thought it did.
>>
>> Relatedly, I think at some point we should add LLVM_EXPORT annotations to
>> APIs in Support/ADT, IR, Target, etc,
>>
>
>
> I agree that it would be absolutely fantastic to support shared library /
> dll builds in the configuration you describe and think we should work
> towards that.
>
> I hope however that we _never_ attempt to do it with annotations like
> LLVM_EXPORT in the source core, nor with export lists. The reason:
>
> 1) They're a complete pain to maintain for developers not working on
> Windows.
>

I don't have a dog in this race either way, but I should point out that if
you build with -fvisibility=hidden and let your annotation expand
to __attribute__((visibility("default"))) while compiling your library and
to nothing for clients of your library, non-Windows shared builds will work
exactly when the the Windows shared build works. (This is how the Chromium
components build works, and it works fairly well there as far as I can
tell.)


>
> 2) Even on Windows, there are at least two possible dynamic linking
> configurations:
>   (a) several modular DLLs
>   (b) LLVM.dll + clang.dll
>   (c) LLVMClang.dll
>
> Annotations could only ever support one of the above given that what's
> exported and what's imported is different for each.
>
>
>  so that we can reduce our .dynsym count and actually support an LLVM.dll
>> on Windows.
>>
>
> So, it strikes me that this problem has great parallels with LTO,
> specifically the task of calculating the minimal set of symbols and
> interdependencies between modules (in this case shared libraries and
> executables).
>
> Perhaps we can treat this as a technology problem and hook into LTO or
> introduce some similar analysis to calculate shared library import /
> exports without having to pepper them throughout the source code.
>
> Rafael and I were discussing something like in person recently. Rafael,
> can you think of a way the LTO machinery could assist in determining DLL
> imports and exports at build time?
>
>
>  However, I know there is *strong* resistance in some camps due to the
>> burden this would impose.
>>
>
> That resistance is valid. Annotations have been a total mess in the
> projects I've seen them applied. Apart from LLVM I'm sure other projects
> like WebKit / Chromium wanting to support DLL builds would benefit from any
> solution we come up with.
>
>
> Alp.
>
>
> --
> http://www.nuanti.com
> the browser experts
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140518/fdbfb634/attachment.html>