search for: cmdsize

...used instead of bzero? Or maybe define a bzero for msvc using memset. For example: // in-memory matches on-disk, so copy first fields followed by path ::memcpy(to, (uint8_t*)&cmd, 12); ::memcpy(&to[12], _name.data(), _name.size()); ::bzero(&to[12+_name.size()], cmdsize-(12+_name.size())); The bzero line could be changed to: ::memset(&to[12+_name.size()], 0, cmdsize-(12+_name.size())); Thanks a lot for the attention and congratulations for the great work!!! Best regards Mello -------------- next part -------------- An HTML attachment was scrubbed... URL:...

...a bzero for msvc > using memset. > > For example: > >       // in-memory matches on-disk, so copy first fields followed by path >       ::memcpy(to, (uint8_t*)&cmd, 12); >       ::memcpy(&to[12], _name.data(), _name.size()); >       ::bzero(&to[12+_name.size()], cmdsize-(12+_name.size())); > > The bzero line could be changed to: > >  ::memset(&to[12+_name.size()], 0, cmdsize-(12+_name.size())); > > Thanks a lot for the attention and congratulations for the great work!!! > > Best regards > Mello While this will make it compile, the c...

...http://www.cornwarning.com/xfer/jccolor.o (from the jpeg library...) jccolor.o: Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags MH_MAGIC_64 X86_64 ALL 0x00 OBJECT 4 432 SUBSECTIONS_VIA_SYMBOLS Load command 0 cmd LC_SEGMENT_64 cmdsize 312 segname vmaddr 0x0000000000000000 vmsize 0x0000000000000900 fileoff 464 filesize 2304 maxprot rwx initprot rwx nsects 3 flags (none) Section sectname __text segname __TEXT addr 0x0000000000000000 size 0x00000000000006b6 offset 464 align 2^4 (16)...

.... > > > > For example: > > > > // in-memory matches on-disk, so copy first fields followed by path > > ::memcpy(to, (uint8_t*)&cmd, 12); > > ::memcpy(&to[12], _name.data(), _name.size()); > > ::bzero(&to[12+_name.size()], cmdsize-(12+_name.size())); > > > > The bzero line could be changed to: > > > > ::memset(&to[12+_name.size()], 0, cmdsize-(12+_name.size())); > > > > Thanks a lot for the attention and congratulations for the great work!!! > > > > Best regards > >...

Hi Kent, My guess is you are getting some new bit of info in your object files and your ranlib(1) is older and doesn't know about it. If you can send me the .o file or the output of otool(1) with the -hlv options on your object file I can take a look. Kev P.S. you can find out the version of ranlib(1) you have by running strings(1) on it and grep(1)'ing for the string

Ran into this today -- rebuilt the SVN Trunk for this morning of LLVM+CLANG. Now every time my builds try and make a library from .o files, ranlib complains about 'malformed object' files. This is with OS X 10.7.4, and the binary tools from XCode 4.4.1 ld -v @(#)PROGRAM:ld PROJECT:ld64-127.2 llvm version 3.0svn, from Apple Clang 3.0 (build 211.12) ranlib doesn't tell you what

On Jun 16, 2012, at 8:23 PM, Cesar Mello wrote: > While this will make it compile, the code is not valid to begin with. > It is trying to do a raw memory copy of a non standard-layout type. > nameoffset is not guaranteed to directly follow cmdsize. Are you saying that in: struct A { int f1; // offset 0 int f2; // offset 4 }; struct B : public A { int f3; // offset 8 ? }; that f3 is not guaranteed to have the same offset it would have had, had it been the third field of A (offset 8)? -Nick -------------- next part...

...ave the build system set an older macOS deployment target. I.e the 6.0.0-rc1 binaries I've just uploaded have the same deployment target problem. Looking at the 5.0.0 and 6.0.0-rc1 binaries, I can confirm that their deployment target was too new: Load command 9 cmd LC_VERSION_MIN_MACOSX cmdsize 16 version 10.12 sdk 10.13 I'm not sure why this is happening, because the build logs are peppered with instances of -mmacosx-version-min=10.9. At any rate, it looks like we currently lack support for inferring an older deployment target based on the triple passed to test-release.sh. It...

...older macOS deployment target. I.e the 6.0.0-rc1 binaries I've just uploaded have the same deployment target problem. > > Looking at the 5.0.0 and 6.0.0-rc1 binaries, I can confirm that their deployment target was too new: > > Load command 9 > cmd LC_VERSION_MIN_MACOSX > cmdsize 16 > version 10.12 > sdk 10.13 > > I'm not sure why this is happening, because the build logs are peppered with instances of -mmacosx-version-min=10.9. > > At any rate, it looks like we currently lack support for inferring an older deployment target based on the triple p...

Hi Zac, Thanks for the heads-up. I've started targeting a minimum macOS deployment target of 10.9 for the release binaries. Hope this helps. Let me know if there are any issues. vedant > On May 1, 2018, at 4:13 PM, Zac Hansen via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The past few packages on http://releases.llvm.org/download.html

The past few packages on http://releases.llvm.org/download.html for mac have required the latest version of mac os. Previously they were built for 10.5 (I believe). I was just wondering if there is a technical reason for this change in requirements and if not, if it could be revered. I have systems I actively use which are 10.10 and 10.11 and it would be awesome if I didn't have to build