<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 8, 2019, 7:12 PM Petr Hosek <<a href="mailto:phosek@chromium.org">phosek@chromium.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Fri, Mar 8, 2019 at 3:37 PM Joel E. Denny <<a href="mailto:jdenny.ornl@gmail.com" target="_blank" rel="noreferrer">jdenny.ornl@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 8, 2019, 6:21 PM Petr Hosek <<a href="mailto:phosek@chromium.org" rel="noreferrer noreferrer" target="_blank">phosek@chromium.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>On Fri, Mar 8, 2019 at 2:55 PM Joel E. Denny <<a href="mailto:jdenny.ornl@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">jdenny.ornl@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Petr,<br>
<br>
On Wed, Mar 6, 2019 at 3:11 AM Petr Hosek <<a href="mailto:phosek@chromium.org" rel="noreferrer noreferrer noreferrer" target="_blank">phosek@chromium.org</a>> wrote:<br>
><br>
> I've implemented <a href="https://reviews.llvm.org/D59013" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D59013</a> which moves libunwind, libc++abi and libc++ output to lib/<target> and include/ in LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build, feedback is welcome.<br>
<br>
Thanks for working on that. Sorry, I was traveling and didn't have a<br>
chance to take a look before you pushed.<br>
<br>
So, if LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=True, then all libraries in<br>
lib/x86_64-unknown-linux-gnu are now early in my library search path.<br>
Is that right?<br>
<br>
One of the objections to previous patches I've seen is that promoting<br>
non-Clang-dedicated directories (that is, their names don't contain<br>
"/clang/") is not safe for backward compatibility because that can<br>
affect library search order for system libraries not installed by<br>
Clang. Doesn't your patch have that issue?<br></blockquote><div><br></div><div>I believe so. Would the alternative be inserting a clang/ component, i.e. lib/clang/x86_64-linux-gnu?</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It sounds sufficient to me. Just to have something to compare to, there was also an example layout here: </div><div dir="auto"><br></div><div dir="auto"><a href="https://reviews.llvm.org/D30733#697781" target="_blank" rel="noreferrer">https://reviews.llvm.org/D30733#697781</a><br></div><div dir="auto"><br></div><div dir="auto">I'm not sure whether that's any better.</div></div></blockquote><div><br></div><div>Personally, I prefer using triples rather than nested directories. It's what Clang already uses setting the target and it's also used by other toolchains and systems.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> I could make that change, my patch has been reverted because it broke Windows bots so I can address this in the reland.</div></div></div></blockquote></div></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Another alternative would be to avoid relying on -L for libraries like libunwind, libc++abi and libc++ which will always have the issue of being a subject to collisions and instead teach the driver to use a full path just like it does for compiler-rt runtimes, but that's a dramatic change.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">What's the advantage over a Clang- dedicated directory that's early in the search path?</div></div></blockquote><div><br></div><div>AFAIK the motivation for using full paths for compiler-rt runtimes compared to e.g. -lgcc_s was <a href="https://en.wikipedia.org/wiki/XcodeGhost" target="_blank" rel="noreferrer">https://en.wikipedia.org/wiki/XcodeGhost</a> which relied on injecting -L to make linker pick up different library than the one shipped with Xcode.</div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Interesting. Can -resource-dir be injected in the same manner to override compiler-rt?</div><div dir="auto"><br></div><div dir="auto">Do users ever depend on being able to specify -L to override Clang's libc++, etc.?</div><div dir="auto"><br></div><div dir="auto">Thanks. </div><div dir="auto"><br></div><div dir="auto">Joel</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> On Wed, Feb 27, 2019 at 10:28 AM Joel E. Denny <<a href="mailto:jdenny.ornl@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">jdenny.ornl@gmail.com</a>> wrote:<br>
>><br>
>> Hi Ilya,<br>
>><br>
>> On Wed, Feb 27, 2019 at 6:08 AM Ilya Biryukov <<a href="mailto:ibiryukov@google.com" rel="noreferrer noreferrer noreferrer" target="_blank">ibiryukov@google.com</a>> wrote:<br>
>> ><br>
>> > Hi Joel,<br>
>> ><br>
>> > clangd, clang-tidy and other tools do not require to be built from the same revision as the host compiler that the project uses to build code. In fact, the compiler is not necessarily clang, it can be gcc or MSVC.<br>
>> > However, the internal clang headers (the ones -resource-dir points at) must correspond to the same version of the code that the clang frontend is built from.<br>
>> > So the aforementioned tools ship their own version of clang's internal headers and pass -resource-dir to the clang frontend to make sure the frontend picks them up. I.e. if the host compiler is also clang, the tools must not pick the host clang's internal headers.<br>
>> > The tools take other compilation arguments from a compilation database (compile_commands.json).<br>
>><br>
>> Thanks. That clears up a lot for me.<br>
>><br>
>> Naively, I would've thought any project (clangd, clang-tidy, or any<br>
>> project external to LLVM) would specify -I to tell the compiler<br>
>> (clang, gcc, or MSVC) where to find the project's required headers<br>
>> when building the project. Using -resource-dir sounds like a special<br>
>> shortcut for the case where the project is clang-based (clangd or<br>
>> clang-tidy) and the compiler building the project is clang. Is that<br>
>> right? What do clangd and clang-tidy specify to the compiler if the<br>
>> compiler is instead gcc or MSVC? Do those have an option equivalent<br>
>> to -resource-dir?<br>
>><br>
>> I don't mean to be arguing against the usage of -resource-dir for this<br>
>> purpose. I'm just trying to understand it.<br>
>><br>
>> ><br>
>> > Note that the internal headers is the only thing that the tools need to override, e.g. this should not affect the C++ standard library found by the tools.<br>
>> > For that to work, we have to make sure the internal headers is the only thing affected by "-resource-dir", we don't want the tools to see a different standard library (or not find a standard library at all).<br>
>><br>
>> Makes sense.<br>
>><br>
>> ><br>
>> > So far in cases where -resource-dir was used for finding libc++, replacing it with "compiler install dir" ("Driver.InstalledDir") seemed to do the job.<br>
>><br>
>> Does "resource-dir used for finding libc++" imply libc++ is in the<br>
>> resource directory and so LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=True?<br>
>><br>
>> Thanks.<br>
>><br>
>> Joel<br>
>><br>
>> ><br>
>> > On Wed, Feb 27, 2019 at 12:09 AM Joel E. Denny <<a href="mailto:jdenny.ornl@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">jdenny.ornl@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Hi Ilya,<br>
>> >><br>
>> >> On Mon, Feb 25, 2019 at 5:32 AM Ilya Biryukov <<a href="mailto:ibiryukov@google.com" rel="noreferrer noreferrer noreferrer" target="_blank">ibiryukov@google.com</a>> wrote:<br>
>> >> ><br>
>> >> > > From this point of view, what LLVM_ENABLE_PER_TARGET_RUNTIME_DIR breaks the tools and the proposed alternative fixes this problem<br>
>> >> > what LLVM_ENABLE_PER_TARGET_RUNTIME_DIR does now ...<br>
>> >> ><br>
>> >> > On Mon, Feb 25, 2019 at 11:31 AM Ilya Biryukov <<a href="mailto:ibiryukov@google.com" rel="noreferrer noreferrer noreferrer" target="_blank">ibiryukov@google.com</a>> wrote:<br>
>> >> >><br>
>> >> >> Using the resource-dir in the header search paths would break tools that use compilation database, e.g. clang-tidy and clangd.<br>
>> >> >> They override the resource-dir as it's very common for them to be built from a different revision than the used compiler. They rely on the fact that the same standard library can be found with the overridden resouce-dir.<br>
>> >> >><br>
>> >> >> From this point of view, what LLVM_ENABLE_PER_TARGET_RUNTIME_DIR breaks the tools and the proposed alternative fixes this problem.<br>
>> >><br>
>> >> Thanks for pointing this out. I'd like to better understand, but I'm<br>
>> >> only familiar with clang-tidy and clangd from a high level. Can you<br>
>> >> explain a bit more about how they interact with the used compiler and<br>
>> >> how they use the overridden resource directory?<br>
>> >><br>
>> >> Thanks.<br>
>> >><br>
>> >> Joel<br>
>> >><br>
>> >> >><br>
>> >> >> On Mon, Feb 25, 2019 at 11:17 AM Petr Hosek via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer noreferrer noreferrer" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>> >> >>><br>
>> >> >>> On Wed, Feb 20, 2019 at 6:14 PM Joel E. Denny <<a href="mailto:jdenny.ornl@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">jdenny.ornl@gmail.com</a>> wrote:<br>
>> >> >>>><br>
>> >> >>>> My alternative to LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is the preceding<br>
>> >> >>>> bullets. In other words, you wouldn't need to specify<br>
>> >> >>>> LLVM_ENABLE_PER_TARGET_RUNTIME_DIR because it would effectively be<br>
>> >> >>>> always on (except the directories might be different than now if the<br>
>> >> >>>> version locking issue is important, as noted above). Is that what<br>
>> >> >>>> you're asking?<br>
>> >> >>><br>
>> >> >>><br>
>> >> >>> That would be my preference. I always hoped that LLVM_ENABLE_PER_TARGET_RUNTIME_DIR would eventually become the default. It would be nice to finish the Darwin support so we can completely deprecate the old layout, but I don't know how far along beanz is in his effort. We should also update openmp to stop using the custom Android-specific runtime layout.<br>
>> >> >>><br>
>> >> >>> There's also the unresolved question of where should libc++ headers and libraries go. Currently, in LLVM_ENABLE_PER_TARGET_RUNTIME_DIR we use the resource dir, but some people expressed the opinion that we shouldn't be using these for libc++ et al. since they're not version-locked to Clang. This is different from what GCC does (e.g. GCC would use $prefix/lib/gcc/x86_64-linux-gnu/8/libstdc++.a) and it's one of the reasons why I used the resource dir for libc++ et al. when implementing LLVM_ENABLE_PER_TARGET_RUNTIME_DIR.<br>
>> >> >>><br>
>> >> >>> So concretely, today LLVM_ENABLE_PER_TARGET_RUNTIME_DIR uses the following layout:<br>
>> >> >>><br>
>> >> >>> headers: $prefix/lib/clang/$version/include(/$triple)(/c++/v1)<br>
>> >> >>> libraries: $prefix/lib/clang/$version/$triple/lib/$name.$ext<br>
>> >> >>><br>
>> >> >>> The alternative that doesn't use resource dir for libc++ would be the following:<br>
>> >> >>><br>
>> >> >>> compiler-rt:<br>
>> >> >>> headers: $prefix/lib/clang/$version/include<br>
>> >> >>> libraries: $prefix/lib/clang/$version/$triple/lib/$name.$ext<br>
>> >> >>><br>
>> >> >>> libc++, libc++abi, libunwind:<br>
>> >> >>> headers: $prefix/include/c++/v1<br>
>> >> >>> libraries: $prefix/lib/$triple/$name.$ext<br>
>> >> >>><br>
>> >> >>> Making this change should be trivial, it's the matter of changing three CMakeLists.txt files (libunwind, libc++abi and libc++) and Clang driver in one place. However, if we're going to make that change, I'd like to get a broader consensus. It'd be also useful to get feedback from libc++ maintainers on this.<br>
>> >> >>> _______________________________________________<br>
>> >> >>> cfe-dev mailing list<br>
>> >> >>> <a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer noreferrer noreferrer" target="_blank">cfe-dev@lists.llvm.org</a><br>
>> >> >>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> --<br>
>> >> >> Regards,<br>
>> >> >> Ilya Biryukov<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > --<br>
>> >> > Regards,<br>
>> >> > Ilya Biryukov<br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Regards,<br>
>> > Ilya Biryukov<br>
<br>
<br>
Joel<br>
<br>
><br>
> On Wed, Feb 27, 2019 at 10:28 AM Joel E. Denny <<a href="mailto:jdenny.ornl@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">jdenny.ornl@gmail.com</a>> wrote:<br>
>><br>
>> Hi Ilya,<br>
>><br>
>> On Wed, Feb 27, 2019 at 6:08 AM Ilya Biryukov <<a href="mailto:ibiryukov@google.com" rel="noreferrer noreferrer noreferrer" target="_blank">ibiryukov@google.com</a>> wrote:<br>
>> ><br>
>> > Hi Joel,<br>
>> ><br>
>> > clangd, clang-tidy and other tools do not require to be built from the same revision as the host compiler that the project uses to build code. In fact, the compiler is not necessarily clang, it can be gcc or MSVC.<br>
>> > However, the internal clang headers (the ones -resource-dir points at) must correspond to the same version of the code that the clang frontend is built from.<br>
>> > So the aforementioned tools ship their own version of clang's internal headers and pass -resource-dir to the clang frontend to make sure the frontend picks them up. I.e. if the host compiler is also clang, the tools must not pick the host clang's internal headers.<br>
>> > The tools take other compilation arguments from a compilation database (compile_commands.json).<br>
>><br>
>> Thanks. That clears up a lot for me.<br>
>><br>
>> Naively, I would've thought any project (clangd, clang-tidy, or any<br>
>> project external to LLVM) would specify -I to tell the compiler<br>
>> (clang, gcc, or MSVC) where to find the project's required headers<br>
>> when building the project. Using -resource-dir sounds like a special<br>
>> shortcut for the case where the project is clang-based (clangd or<br>
>> clang-tidy) and the compiler building the project is clang. Is that<br>
>> right? What do clangd and clang-tidy specify to the compiler if the<br>
>> compiler is instead gcc or MSVC? Do those have an option equivalent<br>
>> to -resource-dir?<br>
>><br>
>> I don't mean to be arguing against the usage of -resource-dir for this<br>
>> purpose. I'm just trying to understand it.<br>
>><br>
>> ><br>
>> > Note that the internal headers is the only thing that the tools need to override, e.g. this should not affect the C++ standard library found by the tools.<br>
>> > For that to work, we have to make sure the internal headers is the only thing affected by "-resource-dir", we don't want the tools to see a different standard library (or not find a standard library at all).<br>
>><br>
>> Makes sense.<br>
>><br>
>> ><br>
>> > So far in cases where -resource-dir was used for finding libc++, replacing it with "compiler install dir" ("Driver.InstalledDir") seemed to do the job.<br>
>><br>
>> Does "resource-dir used for finding libc++" imply libc++ is in the<br>
>> resource directory and so LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=True?<br>
>><br>
>> Thanks.<br>
>><br>
>> Joel<br>
>><br>
>> ><br>
>> > On Wed, Feb 27, 2019 at 12:09 AM Joel E. Denny <<a href="mailto:jdenny.ornl@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">jdenny.ornl@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Hi Ilya,<br>
>> >><br>
>> >> On Mon, Feb 25, 2019 at 5:32 AM Ilya Biryukov <<a href="mailto:ibiryukov@google.com" rel="noreferrer noreferrer noreferrer" target="_blank">ibiryukov@google.com</a>> wrote:<br>
>> >> ><br>
>> >> > > From this point of view, what LLVM_ENABLE_PER_TARGET_RUNTIME_DIR breaks the tools and the proposed alternative fixes this problem<br>
>> >> > what LLVM_ENABLE_PER_TARGET_RUNTIME_DIR does now ...<br>
>> >> ><br>
>> >> > On Mon, Feb 25, 2019 at 11:31 AM Ilya Biryukov <<a href="mailto:ibiryukov@google.com" rel="noreferrer noreferrer noreferrer" target="_blank">ibiryukov@google.com</a>> wrote:<br>
>> >> >><br>
>> >> >> Using the resource-dir in the header search paths would break tools that use compilation database, e.g. clang-tidy and clangd.<br>
>> >> >> They override the resource-dir as it's very common for them to be built from a different revision than the used compiler. They rely on the fact that the same standard library can be found with the overridden resouce-dir.<br>
>> >> >><br>
>> >> >> From this point of view, what LLVM_ENABLE_PER_TARGET_RUNTIME_DIR breaks the tools and the proposed alternative fixes this problem.<br>
>> >><br>
>> >> Thanks for pointing this out. I'd like to better understand, but I'm<br>
>> >> only familiar with clang-tidy and clangd from a high level. Can you<br>
>> >> explain a bit more about how they interact with the used compiler and<br>
>> >> how they use the overridden resource directory?<br>
>> >><br>
>> >> Thanks.<br>
>> >><br>
>> >> Joel<br>
>> >><br>
>> >> >><br>
>> >> >> On Mon, Feb 25, 2019 at 11:17 AM Petr Hosek via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer noreferrer noreferrer" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>> >> >>><br>
>> >> >>> On Wed, Feb 20, 2019 at 6:14 PM Joel E. Denny <<a href="mailto:jdenny.ornl@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">jdenny.ornl@gmail.com</a>> wrote:<br>
>> >> >>>><br>
>> >> >>>> My alternative to LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is the preceding<br>
>> >> >>>> bullets. In other words, you wouldn't need to specify<br>
>> >> >>>> LLVM_ENABLE_PER_TARGET_RUNTIME_DIR because it would effectively be<br>
>> >> >>>> always on (except the directories might be different than now if the<br>
>> >> >>>> version locking issue is important, as noted above). Is that what<br>
>> >> >>>> you're asking?<br>
>> >> >>><br>
>> >> >>><br>
>> >> >>> That would be my preference. I always hoped that LLVM_ENABLE_PER_TARGET_RUNTIME_DIR would eventually become the default. It would be nice to finish the Darwin support so we can completely deprecate the old layout, but I don't know how far along beanz is in his effort. We should also update openmp to stop using the custom Android-specific runtime layout.<br>
>> >> >>><br>
>> >> >>> There's also the unresolved question of where should libc++ headers and libraries go. Currently, in LLVM_ENABLE_PER_TARGET_RUNTIME_DIR we use the resource dir, but some people expressed the opinion that we shouldn't be using these for libc++ et al. since they're not version-locked to Clang. This is different from what GCC does (e.g. GCC would use $prefix/lib/gcc/x86_64-linux-gnu/8/libstdc++.a) and it's one of the reasons why I used the resource dir for libc++ et al. when implementing LLVM_ENABLE_PER_TARGET_RUNTIME_DIR.<br>
>> >> >>><br>
>> >> >>> So concretely, today LLVM_ENABLE_PER_TARGET_RUNTIME_DIR uses the following layout:<br>
>> >> >>><br>
>> >> >>> headers: $prefix/lib/clang/$version/include(/$triple)(/c++/v1)<br>
>> >> >>> libraries: $prefix/lib/clang/$version/$triple/lib/$name.$ext<br>
>> >> >>><br>
>> >> >>> The alternative that doesn't use resource dir for libc++ would be the following:<br>
>> >> >>><br>
>> >> >>> compiler-rt:<br>
>> >> >>> headers: $prefix/lib/clang/$version/include<br>
>> >> >>> libraries: $prefix/lib/clang/$version/$triple/lib/$name.$ext<br>
>> >> >>><br>
>> >> >>> libc++, libc++abi, libunwind:<br>
>> >> >>> headers: $prefix/include/c++/v1<br>
>> >> >>> libraries: $prefix/lib/$triple/$name.$ext<br>
>> >> >>><br>
>> >> >>> Making this change should be trivial, it's the matter of changing three CMakeLists.txt files (libunwind, libc++abi and libc++) and Clang driver in one place. However, if we're going to make that change, I'd like to get a broader consensus. It'd be also useful to get feedback from libc++ maintainers on this.<br>
>> >> >>> _______________________________________________<br>
>> >> >>> cfe-dev mailing list<br>
>> >> >>> <a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer noreferrer noreferrer" target="_blank">cfe-dev@lists.llvm.org</a><br>
>> >> >>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> --<br>
>> >> >> Regards,<br>
>> >> >> Ilya Biryukov<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > --<br>
>> >> > Regards,<br>
>> >> > Ilya Biryukov<br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Regards,<br>
>> > Ilya Biryukov<br>
</blockquote></div></div>
</blockquote></div></div></div>
</blockquote></div></div></div>
</blockquote></div></div></div>