Sam Bishop wrote:> What LLVM is trying to do here is determine its own path. I don't know > if the approach being used will work on Cygwin. (The code is very new, > and it's never worked on Cygwin.) You could try reading the > /proc/$$/exe symlink. I don't know how long Cygwin has been emulating > /proc, though.The dladdr() code won't work on Cygwin; the function isn't available. However, I've attached a (tested) patch which implements the /proc/$$/exe approach.> Once you get past that, the other build errors you'll get will be due to > code assuming that uint32_t is typedefed to int. On 32-bit Cygwin, it's > typedefed to long. (They're the same size, but it still confuses the > compiler.) This is an on-going problem, and I only use Cygwin in a > pinch, so I've just modified the 32-bit typedefs in my > /usr/include/stdint.h file. I've chosen to fight other battles. :)LLVM compiles fine with my stdint.h changes, for what that's worth. Sam -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cygwin-getmainexecutable-impl.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080311/9cd79853/attachment.ksh>
On Mar 11, 2008, at 8:10 PM, Sam Bishop wrote:> Sam Bishop wrote: >> What LLVM is trying to do here is determine its own path. I don't >> know >> if the approach being used will work on Cygwin. (The code is very >> new, >> and it's never worked on Cygwin.) You could try reading the >> /proc/$$/exe symlink. I don't know how long Cygwin has been >> emulating >> /proc, though. > > The dladdr() code won't work on Cygwin; the function isn't > available. However, I've attached a (tested) patch which implements > the /proc/$$/exe approach.Looks good to me, applied: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080310/059671.html Please attach patches as attachments (and name the file ".patch" just in case). Mail readers commonly munge them (e.g. by removing trailing whitespace) if not, which prevents the patch from applying. Thanks Sam! -Chris
> Please attach patches as attachments (and name the file > ".patch" just in case). Mail readers commonly munge them > (e.g. by removing trailing whitespace) if not, which prevents > the patch from applying.I hope that this is not off-topic, but why is this? I'm doing some amount of linux-driver kernel work, and there you are urged to insert your patch directly into the body, not as an attachment. What you have to do is to disable word-wrapping. The various kernel subsystem maintainers then directly put the patches from their mailclients into git, and trailing whitespace doesn't seem to be a problem there. The benefit is that various web-based mailing list archives have the code snippets there directly, so they end up eventually in google. You can also much better comment on those patches, replying and writing your stuff in-between. For reference, here's an excerpt from linux/Documentation/SubmittingPatches: ------------------------------------------- 7) No MIME, no links, no compression, no attachments. Just plain text. Linus and other kernel developers need to be able to read and comment on the changes you are submitting. It is important for a kernel developer to be able to "quote" your changes, using standard e-mail tools, so that they may comment on specific portions of your code. For this reason, all patches should be submitting e-mail "inline". WARNING: Be wary of your editor's word-wrap corrupting your patch, if you choose to cut-n-paste your patch. Do not attach the patch as a MIME attachment, compressed or not. Many popular e-mail applications will not always transmit a MIME attachment as plain text, making it impossible to comment on your code. A MIME attachment also takes Linus a bit more time to process, decreasing the likelihood of your MIME-attached change being accepted. Exception: If your mailer is mangling patches then someone may ask you to re-send them using MIME. WARNING: Some mailers like Mozilla send your messages with ---- message header ---- Content-Type: text/plain; charset=us-ascii; format=flowed ---- message header ---- The problem is that "format=flowed" makes some of the mailers on receiving side to replace TABs with spaces and do similar changes. Thus the patches from you can look corrupted. To fix this just make your mozilla defaults/pref/mailnews.js file to look like: pref("mailnews.send_plaintext_flowed", false); // RFC 2646======pref("mailnews.display.disable_format_flowed_support", true); -------------------------------------------
On Wed, March 12, 2008 11:23 pm, Chris Lattner wrote:> Please attach patches as attachments (and name the file ".patch" just > in case). Mail readers commonly munge them (e.g. by removing trailing > whitespace) if not, which prevents the patch from applying.Hmm... What you got was the result of me telling Thunderbird to attach a file called cygwin-getmainexecutable-impl.patch. You can see here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-March/013029.html All of my previous patches have been sent using SquirrelMail. It looks like I'll keep doing that... Thanks, Sam