llvm dev - Mar 2008 - [LLVMdev] Subversion head: build problem on cygwin?

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