similar to: [LLD][COFF] Zero linker-version header field breaks Authenticode on Windows 7

> From: Rui Ueyama [mailto:ruiu at google.com] > Sent: 21 June 2017 15:23 > > lld-link already has an option to specify version. Please try to add > "/version:14.0" to your command line. That doesn't affect the same version field. The number I put in there goes into the MajorImageVersion and MinorImageVersion fields, whereas to solve this signature issue I need to

Is anyone else working on a COFF linker for LLVM ? Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100617/a3c9c8a4/attachment.html>

I am trying to get signtool.exe, which is part of the Microsoft Platform SDK, working under the latest version of Wine on my Fedora Core 5 box. When I run signtool.exe, I get the following errors: err:module:import_dll Loading library CRYPTUI.dll (which is needed by L"C:\\signing\\signtool.exe") failed (error c0000020). err:module:LdrInitializeThunk Main exe initialization for

Dear all, My colleague, who has been helping me with wrapping some older C++ code for use in R, has been running into some issues, which he asked me to post here: - ERROR is defined in RS.h which is included in Rdefines.h which conflicts with Visual Studio's ERROR - TRACE is defined in Rinternals.h which conflicts with Visual Studio's TRACE - math.h is included within extern

ok i have been using linux for about three days now and i must say it is pretty cool. my only problem is that when i tried to update halo pc to play online wine froze. so when i tried to do it manually by clicking on halo update.exe everything seemed to download fine until it started to update. then it had some weird error about internet explorer. here is a picture [Image:

>From my own experience this is what I think happens when building the whole solution through Visual Studio's UI. This also happens for building individual projects. I assume something similar happens when building via the command-line, but I rarely do that, so I can't be certain. 1) Visual Studio/MSBuild (I don't know which, but probably MSBuild) determines the dependency graph of

We're in the process of importing lld into FreeBSD (along with our Clang 3.9 update project). For now I've removed all but the ELF linker[1]. We have no need for COFF and Mach-O, and we have a bespoke build system for all of our contrib code. I didn't bother adding build support for the source files for non-ELF linkers. Is this something that'd be reasonable / desirable to have

>From what I've read, you can build/use LLVM+clang via Visual Studio or via MinGW. So far, I've only managed to have my code working via MinGW. However, most of my users compile using Visual Studio. Can LLVM that was compiled using MinGW (or using the pre-built MinGW binary) be linked against using Visual Studio (or, more specifically, using Visual Studio's "cl"

On 12 September 2016 at 16:23, Rui Ueyama <ruiu at google.com> wrote: > What's the motivation to not build COFF and Mach-O parts? If you don't need > it, you could just leave it. Are you trying to reduce the executable size? It was just easier to remove coff::link() and mach_o::link() from lld.cpp than to add them to our own build infrastructure

It looks like building ZERO_CHECK first to reconstruct the project files as needed, then running msbuild a second time to do the actual build, has solved the problem. At least, last night's run didn't take the usual two tries. Running msbuild twice is a little bit simpler than running cmake explicitly, the way I have my scripts set up, but I'm sure that would work as well. Thanks

With VS2013 I found that editing a CMakeLists.txt file caused CMake to be re-run successfully and the build to also continue successfully, but since I switched to VS2015 the CMake re-run occurs - apparently successfully, but more often than not the build failed afterwards from either the IDE and from MSBuild. Since I seldom change the CMakeLists.txt files, I simply do a clean CMake configuration

Hello, I've switched to R studio from the StatET Eclipse plug-in. I have a question regarding navigating between plots. When I use x11() or windows() new devices are created and I know how to switch back and forth between them. However, when I plot on the device that stands for R-Studio's built-in plot browser, is there a way to switch back between plots? Each new "plot"

Hello. I wonder how I can use the options of LLVM commands in Visual Studio Debugging mode. For example, If I want to follow the pass on 'llc -march=x86 hello.bc' in the Visual Studio's debuggin mode, how can I let it know the options such as '-march=x86 hello.bc'? I can set the breakpoint in main() in llc.cpp but I can't let it cognize that I want X86 assembly code from

On 3/30/2017 7:59 PM, Reid Kleckner via llvm-dev wrote: > On Thu, Mar 30, 2017 at 6:08 AM, Edward Diener via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Are you saying that once lld is built with mingw-64/gcc on Windows > it is impossible to tell it to handle PE/COFF files when invoking it > from clang++ using the

On 3/30/2017 9:03 PM, Reid Kleckner via llvm-dev wrote: > On Thu, Mar 30, 2017 at 5:57 PM, Edward Diener via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Actually just doing: > > clang++ -c t.cpp -o t.o --target=x86_64-windows-msvc -fmsc-version=1900 > clang++ t.o -o t.exe --target=x86_64-windows-msvc

Has anyone ever thought configuring asterisk on a pair of pc's to act as remote broadcast terminals for the broadcast radio industry? Seems like a stripped down asterisk on a laptop with a PCMCIA ISDN modem connecting to another asterisk instance on a PC at a radio station would work nicely. Use one of the higher quality codecs, interface the remote mixer to the sound card on the

--- win32/VS2015/opus.vcxproj | 2 ++ win32/VS2015/opus.vcxproj.filters | 6 ++++++ 2 files changed, 8 insertions(+) diff --git a/win32/VS2015/opus.vcxproj b/win32/VS2015/opus.vcxproj index d9aaa03..f55ea37 100644 --- a/win32/VS2015/opus.vcxproj +++ b/win32/VS2015/opus.vcxproj @@ -852,6 +852,7 @@ <ClInclude Include="..\..\celt\vq.h" /> <ClInclude

Avoids trying to create and replace version.h more than once which led to file-locking errors with multicore builds. --- Makefile.am | 1 + win32/VS2015/celt.vcxproj | 48 +++++++++++++++++--------- win32/VS2015/generate_version.vcxproj | 65 +++++++++++++++++++++++++++++++++++ win32/VS2015/opus.sln | 32 ++++++++++++++++-

Using -i should prevent failing if the files don't exist. --- appveyor.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/appveyor.yml b/appveyor.yml index c85b0b1..ad9c6c0 100644 --- a/appveyor.yml +++ b/appveyor.yml @@ -17,7 +17,7 @@ build: verbosity: minimal after_build: -- cmd: 7z a opus.zip win32\VS2015\%PLATFORM%\%CONFIGURATION%\opus.lib include\*.h +- cmd: 7z

AFAICT we traditionally only support building llvm/clang with the 2 most recent releases of Visual Studio. With the release of VS2019, what do people think of retiring VS2015 support before the next major llvm/clang release? As well as simplifying C++14 migration (admittedly only a little), this should also let us remove a number of hacks (e.g. the alignas/AlignedCharArray hack in