similar to: [LLVMdev] modify cmakefiles to set the default triple of msvc and mingw to i686-pc-mingw

"罗勇刚(Yonggang Luo)" <luoyonggang at gmail.com> writes: > because on windows platform. i686-pc-winnt is not mature and even > don't working. So the it's better to set it to mingw. Is this right? There are some differences among mingw and msvc (the C++ `this' calling convention, for instance). BTW, it's i686-pc-win32, not i686-pc-winnt. > And also those

On Sun, Aug 9, 2009 at 10:03 AM, Óscar Fuentes<ofv at wanadoo.es> wrote: >> Also, now msvc support multiple target. So it's better to set it as >> ${LLVM_ALL_TARGETS} >> It's can working, why not set it to:. > > I think most LLVM users on Windows are interested on X86 only. This > saves a lot of time on the build process and creates smaller >

Eli Friedman <eli.friedman at gmail.com> writes: > On Sun, Aug 9, 2009 at 10:03 AM, Óscar Fuentes<ofv at wanadoo.es> wrote: >> I think most LLVM users on Windows are interested on X86 only. This >> saves a lot of time on the build process and creates smaller >> executables. Anyways, it they want all targets, it is simply a matter of >> passing

On Sun, Aug 9, 2009 at 1:04 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: > Eli Friedman <eli.friedman at gmail.com> writes: > >> On Sun, Aug 9, 2009 at 10:03 AM, Óscar Fuentes<ofv at wanadoo.es> wrote: >>> I think most LLVM users on Windows are interested on X86 only. This >>> saves a lot of time on the build process and creates smaller >>>

Am 09.08.09 23:36, schrieb Eli Friedman: > > MSVC *is* continuously checked; see > http://google1.osuosl.org:8011/builders/clang-i686-xp-msvc9. Anyone > who breaks the MSVC build will get a nastygram from buildbot. > Please note that the MSVC buildbot only builds the X86 target at the moment. I don't know why though.

Eli Friedman <eli.friedman at gmail.com> writes: > MSVC *is* continuously checked; see > http://google1.osuosl.org:8011/builders/clang-i686-xp-msvc9. Anyone > who breaks the MSVC build will get a nastygram from buildbot. This is new news for me. If the developer who broke the msvc build receives a nastygram, would he urged to fix it when he has no msvc compiler and probably no

On Sun, Aug 9, 2009 at 3:35 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: > Eli Friedman <eli.friedman at gmail.com> writes: > >> MSVC *is* continuously checked; see >> http://google1.osuosl.org:8011/builders/clang-i686-xp-msvc9.  Anyone >> who breaks the MSVC build will get a nastygram from buildbot. > > This is new news for me. > > If the developer

-- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm.patch Type: application/octet-stream Size: 14374 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090805/4328d661/attachment.obj>

I means visual studio c++ 2008, do you build clang+llvm with .sln files, and these files are generated by cmake? I do of that. And because vs c++ can't recognize path such a:/filepath/.. Properlyn it's recognized as a:/filepath So we need change /.. to /../ or /../. 2009/8/6, Daniel Dunbar <daniel at zuster.org>: > I don't understand this problem, I have built clang on

Notice!! sorry for that, the patch is incorrect, i attached the new one. -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- A non-text attachment was scrubbed... Name: triple.patch Type: application/octet-stream Size: 3745 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090815/9429c396/attachment.obj>

The buildbot ever showed that cmake generating the msvc sln file failure, but few days later, it's fixed. How it's fixed, I doesn't see the information. Is it downgrade the msvc or other solutions? -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo

For example, ELF.h MachO.h and COFF.h should moved into Object directory with new name. and Dwarf.h should moved into DebugInfo directory. 2013/6/29 Eric Christopher <echristo at gmail.com>: > Where would you like to move them? > > -eric > > On Fri, Jun 28, 2013 at 10:38 AM, 罗勇刚(Yonggang Luo) > <luoyonggang at gmail.com> wrote: >> From my point of view, the

Well, is that possible to include libstdc++4.7 into llvm? On Wed, Jun 29, 2016 at 2:26 AM, Brian Cain <brian.cain at gmail.com> wrote: > Sorry if I was unclear, I have no problems building clang against a newer > gcc for my own purpose. But it doesn't make sense to provide a release > binary for clang that's hosted on llvm.org that's ostensibly for >

It is possible to statically link against libstdc++, yes. I don't quite know all the pieces to the recipe in order to get that to work. It would require changes to the release script in order to get those configuration changes all the way through the third phase build. I don't believe any other tarball release does this, so it would at least be an unconventional release. On Wed, Jun

>From my point of view, the Support library should be more pure. And should not contains too much LLVM-related APIs and defines, -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo

2013/10/19 Rafael Espíndola <rafael.espindola at gmail.com>: > On 19 October 2013 06:01, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com> wrote: >> I found that access llvm-mc from clang driver is impossible, and I >> want to use llvm-mc to compile assembly files, how to do that? > > Try "clang -integrated-as -c test.s" Thank you very much, I use the

Going to be interesting layering issues if you do the latter. Then you have CodeGen depending upon DebugInfo instead of just a header in Support. -eric On Fri, Jun 28, 2013 at 11:08 AM, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com> wrote: > For example, > ELF.h MachO.h and COFF.h > should moved into Object directory with new name. > and Dwarf.h should moved into DebugInfo

Hell, Brian, I found a way to install Gcc 5.3 on CentOS 6 without the need to building it from source. You may try it on CentOS 6.0 That's makes clang/llvm won't depends on the newer version of glibc 2.14 The instruction: vim /etc/yum.repos.d/llvm.repo The content: ``` [sclo] name=SCLO baseurl=http://mirror.centos.org/centos/6/sclo/x86_64/rh/ gpgcheck=0 enabled=1 ``` Installation step:

So CentOS before 6.7 is not an option after all? Is that possible to use clang on CentOS 6.6 and before? On Wed, Jun 29, 2016 at 12:48 AM, Brian Cain <brian.cain at gmail.com> wrote: > Yes, I believe it was built against centos 6.7. I wanted to build it > against an older release but couldn't quite bootstrap it without newer > libstdc++. > > Sorry, it would be clearer

The patch is for version 77784 And it's fixed the cmake for eclipse win32 mingw makefile output:) Also a warning in VS 2008 on stub.c Hope someone apply this patch. And those files that place the <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> Before <title> is just because of in tag title may contains strange characters such as Chinese