search for: crts

...uced a bunch of condition variable APIs that I know less about, but that's another reason we might want to raise our base requirement as people look into parallel LTO and codegen. It also seems likely that we will want to use some of the new C++11 library features that are only present in newer CRTs, which don't run on XP. Please respond if you have any objections. If there are no strong objections, I think we can start using Vista+ APIs in a week or so. We can still change our minds and revert stuff before the release if users feel this is too short notice. -------------- next part -----...

On 6.5.2013 0:43, Timothy B. Terriberry wrote: > Janne Hyv?rinen wrote: >> You people do realize these hacks would only be required for 10+ year >> old obsolete compilers? > No, they're required for easy distribution on 12 year old OSes (which, > last I saw, make up almost 40% of Firefox's desktop userbase, and likely > will continue to for some time). > What

Hello all; Is anyone knows if it's possible to have a dual certificate setup on dovecot like in postfix or apache ? i tried to add several crts in local name section : local_name imap.server.tdl { ssl_cert = <server_rsa_crt.pem ssl_key = <server_rsa_key.pem ssl_cert = <server_ecdsa_crt.pem ssl_key = <server_ecdsa_key.pem } but it seems that dovecot takes the last one (ecdsa) and that rsa cert is not used. to check if booth...

I've found that interception_win.cc line 835: "msvcr110.dll" //VS2012 "msvcr120.dll" //VS2013 interception is supported by commit 916b81 3 years ago , currently I'm build project with msvc100 , application will crash in un-intercepted free. adding msvcr100.dll to this list makes sanitizer working correctly , I wonder if compiler rt can including this msvc100.dll

...Windows specifically, I’m not even sure it’s going to be physically possible to link in two copies of the CRT and have one forward to the other. If it is possible, it’s very non obvious how to make it work and will likely require a ton of additional machinery. No, I do not think we want to mix up CRTs on any platform. At the least, it will be disruptive to the compiler drivers. Our goal is to build a CRT with supports statically linked executables on Linux. We do not intend to mix this new CRT with the CRT from the system libc. The new CRT might only be useful after a non-trivial part of the lib...

...nly applied to monochrome > monitors, and maybe early cga. I seem to remember that screen savers were > just eye candy. In this particular case, burn-in will most certainly occur. TiVo is connected to televisions, and big screen TVs are very susceptible to burn in because of how hard the CRTs are driven to produce a large picture. There are tons of horror stories on the 'net about it from people who left them on news channels for days after 9/11, or watched 4:3 material unstretched on a 16:9 screen for long periods of time. On PCs though, you are correct, burn in is pretty much...

On Thu, Jun 27, 2019 at 3:56 PM Zachary Turner <zturner at roblox.com> wrote: > No, I do not think we want to mix up CRTs on any platform. At the >> least, it will be disruptive to the compiler drivers. Our goal is to >> build a CRT with supports statically linked executables on Linux. We >> do not intend to mix this new CRT with the CRT from the system libc. >> The new CRT might only be useful...

Hi, All, I follow the menu http://llvm.org/docs/GettingStartedVS.html , but still failed to build LLVM debug version. Here's error message: 7>C:\study\llvm\projects\compiler-rt\lib\asan\asan_win.cc(69): fatal error C1189: #error : Please build the runtime with a non-debug CRT: /MD or /MT Any idear? -- Best Regards, Amy -------------- next part -------------- An HTML attachment was

...uced a bunch of condition variable APIs that I know less about, but that's another reason we might want to raise our base requirement as people look into parallel LTO and codegen. It also seems likely that we will want to use some of the new C++11 library features that are only present in newer CRTs, which don't run on XP. Please respond if you have any objections. If there are no strong objections, I think we can start using Vista+ APIs in a week or so. We can still change our minds and revert stuff before the release if users feel this is too short notice. ______________________________...

Thanks for the note. I had never seen anything in the postfix and apache documentation that the CRLs could be intermingled with the CRTs in the CRT file. The documentation for those programs suggests putting the CRLs in a separate file (e.g. apache SSLCARevocationFile) or doesn't talk about putting CRLs in with the certs (e.g. postfix smtpd_tls_cert_file). If it works to put them all in one file for those programs, that's go...

...PIs that I know less >> about, but that's another reason we might want to raise our base >> requirement as people look into parallel LTO and codegen. It also seems >> likely that we will want to use some of the new C++11 library features that >> are only present in newer CRTs, which don't run on XP. >> >> >> >> Please respond if you have any objections. If there are no strong >> objections, I think we can start using Vista+ APIs in a week or so. We can >> still change our minds and revert stuff before the release if users feel &gt...

...but that's another reason we might want to raise our base requirement >>>>> as people look into parallel LTO and codegen. It also seems likely that we >>>>> will want to use some of the new C++11 library features that are only >>>>> present in newer CRTs, which don't run on XP. >>>>> >>>>> >>>>> >>>>> Please respond if you have any objections. If there are no strong >>>>> objections, I think we can start using Vista+ APIs in a week or so. We can >>>>> stil...

...but that's another reason we might want to raise our base > requirement > >>> as people look into parallel LTO and codegen. It also seems likely > that we > >>> will want to use some of the new C++11 library features that are only > >>> present in newer CRTs, which don't run on XP. > >>> > >>> > >>> > >>> Please respond if you have any objections. If there are no strong > >>> objections, I think we can start using Vista+ APIs in a week or so. We > can > >>> still change our...

...monitors_config->max_allowed. Drops pointless indirection > > and also is less confusing. > > > > To me is MORE confusing, why comparing number of something with > another number? Previously code was comparing number of monitors > with number of monitors, not number of CRTs with number of > monitors. Yes, spice/qxl and drm/kms use slightly different terminology. drm crtc == qxl monitor. drm framebuffer == qxl surface. You need to know that anyway when looking at the qxl ksm code. We have function names like qxl_crtc_update_monitors_config(). I fail to see why...

...n > > > > and also is less confusing. > > > > > > > > > > To me is MORE confusing, why comparing number of something with > > > another number? Previously code was comparing number of monitors > > > with number of monitors, not number of CRTs with number of > > > monitors. > > > > Yes, spice/qxl and drm/kms use slightly different terminology. > > > > drm crtc == qxl monitor. > > drm framebuffer == qxl surface. > > > > You need to know that anyway when looking at the qxl ksm code. We...

Hello, I have several CentOS 6 VMs, I have updated the first one successfully, but there is one thing I miss or I don't like; How do I get the standard console with 80x25 back? Hello, this is /boot/grub/grub.conf default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.32-642.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-642.el6.x86_64 ro

...age and some of the FLAC API functions, though, that actually was the reason I linked FLAC against msvcrt.dll in the first place. The metadata object functions can be used in a memory ownership transferring manner. Doing so will cause problems when the calling EXE and the FLAC DLL use different CRTs as the DLL's CRT will not know about memory allocated by the EXE's CRT. However, the same happens when you mix msvcrt.dll and msvcr??.dll, so it's not limited to static linkage only. It's getting a bit off topic here, though...

...er reason we might want to raise our base >> requirement >> >>> as people look into parallel LTO and codegen. It also seems likely >> that we >> >>> will want to use some of the new C++11 library features that are only >> >>> present in newer CRTs, which don't run on XP. >> >>> >> >>> >> >>> >> >>> Please respond if you have any objections. If there are no strong >> >>> objections, I think we can start using Vista+ APIs in a week or so. >> We can >> &g...

...the FLAC API > functions, though, that actually was the reason I linked FLAC against > msvcrt.dll in the first place. The metadata object functions can be used > in a memory ownership transferring manner. Doing so will cause problems > when the calling EXE and the FLAC DLL use different CRTs as the DLL's > CRT will not know about memory allocated by the EXE's CRT. However, the > same happens when you mix msvcrt.dll and msvcr??.dll, so it's not > limited to static linkage only. It's getting a bit off topic here, > though... > ______________________________...

...>> >>> requirement >>> >>> as people look into parallel LTO and codegen. It also seems likely >>> >>> that we >>> >>> will want to use some of the new C++11 library features that are only >>> >>> present in newer CRTs, which don't run on XP. >>> >>> >>> >>> >>> >>> >>> >>> Please respond if you have any objections. If there are no strong >>> >>> objections, I think we can start using Vista+ APIs in a week or so. >&gt...