You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2004/01/18 06:15:45 UTC
Re: svn commit: r8372 - branches/1.0-stabilization
On Sun, 2004-01-18 at 00:03, kfogel@tigris.org wrote:
> + * r8343
> + Use 'unsigned char secret[64]' instead of 'char secret[64]'.
> + Justification: SVN won't compile on AIX with xlc without this.
> + Votes:
> + +1: kfogel
But SVN won't compile with xlc with this change either, due to the
volatile sig_atomic_t issue. So, r8343 would make sense if combined
with a workaround for that issue (although there is no good workaround),
but it doesn't make a lot of sense by itself.
(Not that it does any harm, of course.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] faq to help xlc users compile
Posted by Travis P <sv...@castle.fastmail.fm>.
On Jan 25, 2004, at 1:20 PM, Greg Hudson wrote:
> On Sun, 2004-01-25 at 13:08, Travis P wrote:
>> +<p>By default, xlc compiles to a strict standard which is in minor
>> +conflict with Subversion code in just a couple places.
>
> That's not an accurate characterization of the current problem. xlc is
> simply buggy in this respect; a compiler must accept duplicate volatile
> qualifiers and most definitely must accept "volatile sig_atomic_t".
>
> (The other problem, which was a signed/unsigned conflict in cram.c, has
> been fixed on the mainline and on the 1.0-stabilization branch, and
> thus
> in the 0.37 release.)
Sure. I tried to avoid the detail by saying "a strict standard" with
no implication
of whose standard was implemented or whether anyone is right or wrong.
And
the CFLAGS suggestion will make compilation more likely to work, even
if the volatile
issue is resolved but another similar issue pops up in the future.
Avoid specific
mention of the need for the suggestion may thus avoid a faq change.
Anyway, those were my thoughts. I've revised the patch below. There
are two versions. Both reworded.
One mentioning duplicate volatile. The other does not. Take your pick.
-Travis
____________________________________
Add FAQ item about compiling with xlc.
* www/project_faq.html
(xlc-compile): New item.
Index: project_faq.html
===================================================================
--- project_faq.html (revision 8515)
+++ project_faq.html (working copy)
@@ -111,6 +111,8 @@
file, but svn says something about "path not found". What's going
on?</a></li>
<li><a href="#digest-auth">Why doesn't HTTP Digest auth work?</a></li>
+<li><a href="#xlc-compile">Compiling with xlc on AIX, I get compilation
+ errors. What's wrong?</a></li>
@@ -1448,6 +1450,17 @@
to see if the description there matches your symptoms.
</p>
+<![CDATA[-----------------------------------------------------------]]>
+
+<h3><a name="xlc-compile">Compiling with xlc on AIX, I get compilation
+ errors. What's wrong?</a></h3>
+
+<p>Adding <tt>-qlanglvl=extended</tt> to the
+environment variable CFLAGS for configuration and build
+will make xlc a bit more flexible and the code will
+compile without error.
+</p>
+
<![CDATA[=========================================================]]>
Index: project_faq.html
===================================================================
--- project_faq.html (revision 8515)
+++ project_faq.html (working copy)
@@ -111,6 +111,8 @@
file, but svn says something about "path not found". What's going
on?</a></li>
<li><a href="#digest-auth">Why doesn't HTTP Digest auth work?</a></li>
+<li><a href="#xlc-compile">Compiling with xlc on AIX, I get compilation
+ errors. What's wrong?</a></li>
@@ -1448,6 +1450,18 @@
to see if the description there matches your symptoms.
</p>
+<![CDATA[-----------------------------------------------------------]]>
+
+<h3><a name="xlc-compile">Compiling with xlc on AIX, I get compilation
+ errors. What's wrong?</a></h3>
+
+<p>By default, xlc complains about duplicate volatile
+qualifiers. Adding <tt>-qlanglvl=extended</tt> to the
+environment variable CFLAGS for configuration and build
+will make xlc a bit more flexible and the code will
+compile without error.
+</p>
+
<![CDATA[=========================================================]]>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] faq to help xlc users compile
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2004-01-25 at 13:08, Travis P wrote:
> +<p>By default, xlc compiles to a strict standard which is in minor
> +conflict with Subversion code in just a couple places.
That's not an accurate characterization of the current problem. xlc is
simply buggy in this respect; a compiler must accept duplicate volatile
qualifiers and most definitely must accept "volatile sig_atomic_t".
(The other problem, which was a signed/unsigned conflict in cram.c, has
been fixed on the mainline and on the 1.0-stabilization branch, and thus
in the 0.37 release.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] faq to help xlc users compile
Posted by Travis P <sv...@castle.fastmail.fm>.
On Jan 23, 2004, at 11:40 AM, kfogel@collab.net wrote:
> Travis P <sv...@castle.fastmail.fm> writes:
>> I originally reported it and I think that that is fine, but I do think
>> that
>> documentation mentioning that the "-qlanglvl=extended" flag is
>> recommended for xlc compilation might be a nice touch.
>
> Hmm, can you make a new FAQ item for this, by producing a patch
> against www/project_faq.html in the Subversion tree? That would be a
> big help.
>
Sure. It's below. I waited to double-check that the advice works on a
nice clean 0.37. It does.
I don't mention that I only built the client as the advice should also
apply to anyone trying to build the server as well.
Just FYI: xlc compilers are also now available for MacOS X so assuming
xlc and AIX go hand-in-hand may be erroneous.
( Ref:
http://www-306.ibm.com/common/ssi/fcgi-bin/ssialias?
infotype=an&subtype=ca&supplier=897&appname=IBMLinkRedirect&letternum=EN
US204-005 )
While I wouldn't expect to find its use particularly prevalent, in
high-performance scientific applications such as the Virginia Tech G5
Supercomputing Cluster, it has already reportedly been used.
There's a lot of other experience that perhaps should be documented
somewhere--especially since the list archives searchability appears
sketchy. Search for xlc or aix and you will not find any of my recent
posts to the dev or users lists and the various ensuing conversations
-- I didn't anyway. I also do not see a way to order search results by
date, which will likely be more and more a problem as time progresses
and suggestions about alpha-level Subversion may precede more relevant
discussions about newer versions of Subversion.
-Travis Pouarz
____________________________________
Add FAQ item about compiling with xlc.
* www/project_faq.html
(xlc-compile): New item.
Index: project_faq.html
===================================================================
--- project_faq.html (revision 8515)
+++ project_faq.html (working copy)
@@ -111,6 +111,8 @@
file, but svn says something about "path not found". What's going
on?</a></li>
<li><a href="#digest-auth">Why doesn't HTTP Digest auth work?</a></li>
+<li><a href="#xlc-compile">Compiling with xlc on AIX, I get compilation
+ errors. What's wrong?</a></li>
@@ -1448,6 +1450,18 @@
to see if the description there matches your symptoms.
</p>
+<![CDATA[-----------------------------------------------------------]]>
+
+<h3><a name="xlc-compile">Compiling with xlc on AIX, I get compilation
+ errors. What's wrong?</a></h3>
+
+<p>By default, xlc compiles to a strict standard which is in minor
+conflict with Subversion code in just a couple places. Adding
+<tt>-qlanglvl=extended</tt> to the environment variable CFLAGS
+for configuration and build will make xlc a bit more flexible
+and the code will compile without error.
+</p>
+
<![CDATA[=========================================================]]>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r8372 - branches/1.0-stabilization
Posted by kf...@collab.net.
Travis P <sv...@castle.fastmail.fm> writes:
> I originally reported it and I think that that is fine, but I do think
> that
> documentation mentioning that the "-qlanglvl=extended" flag is
> recommended for xlc compilation might be a nice touch.
Hmm, can you make a new FAQ item for this, by producing a patch
against www/project_faq.html in the Subversion tree? That would be a
big help.
Thanks,
-Karl
> Along that line of thought, I don't see any file or directory of files
> that contain platform/os/compiler caveats where workarounds for
> differences can be documented. Some problems may be better
> handled that way (for whatever reason) than by Subversion changes.
We could do this via individual FAQ items until/unless there are a lot
of them, then try something more organized.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r8372 - branches/1.0-stabilization
Posted by Travis P <sv...@castle.fastmail.fm>.
On Jan 22, 2004, at 11:30 AM, Greg Hudson wrote:
> I wrote:
>>> If we do want to go this route, here's a patch. (I have no
>>> particular emotional attachment to it, but I'm one of the
>>> relatively few people in the project who does do autoconf.)
>
> Karl wrote:
>> Cool.
>
>> IMHO such at patch belongs on trunk, but not in 1.0 at this point.
>> It means xlc users have to either use GCC, or apply a tweak, but
>> hey, stabilization always comes at a price.
>
> I've decided I don't think it belongs at all. It's too much hair to
> work around a bug in a fairly obscure compiler.
I originally reported it and I think that that is fine, but I do think
that
documentation mentioning that the "-qlanglvl=extended" flag is
recommended for xlc compilation might be a nice touch.
Along that line of thought, I don't see any file or directory of files
that contain platform/os/compiler caveats where workarounds for
differences can be documented. Some problems may be better
handled that way (for whatever reason) than by Subversion changes.
-Travis Pouarz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r8372 - branches/1.0-stabilization
Posted by Greg Hudson <gh...@MIT.EDU>.
I wrote:
>> If we do want to go this route, here's a patch. (I have no
>> particular emotional attachment to it, but I'm one of the
>> relatively few people in the project who does do autoconf.)
Karl wrote:
> Cool.
> IMHO such at patch belongs on trunk, but not in 1.0 at this point.
> It means xlc users have to either use GCC, or apply a tweak, but
> hey, stabilization always comes at a price.
I've decided I don't think it belongs at all. It's too much hair to
work around a bug in a fairly obscure compiler.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r8372 - branches/1.0-stabilization
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> On Sun, 2004-01-18 at 09:17, Philip Martin wrote:
> > The way to handle it is an autoconf macro (perhaps for AIX/xlc only)
> > that attempts to compile volatile sig_atomic_t.
>
> If we do want to go this route, here's a patch. (I have no particular
> emotional attachment to it, but I'm one of the relatively few people in
> the project who does do autoconf.)
Cool.
IMHO such at patch belongs on trunk, but not in 1.0 at this point. It
means xlc users have to either use GCC, or apply a tweak, but hey,
stabilization always comes at a price.
(I realize you weren't necessarily advocating that it go into 1.0.)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r8372 - branches/1.0-stabilization
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2004-01-18 at 09:17, Philip Martin wrote:
> The way to handle it is an autoconf macro (perhaps for AIX/xlc only)
> that attempts to compile volatile sig_atomic_t.
If we do want to go this route, here's a patch. (I have no particular
emotional attachment to it, but I'm one of the relatively few people in
the project who does do autoconf.)
Re: svn commit: r8372 - branches/1.0-stabilization
Posted by Philip Martin <ph...@codematters.co.uk>.
Greg Hudson <gh...@MIT.EDU> writes:
> SVN won't compile with xlc with this change either, due to the
> volatile sig_atomic_t issue. So, r8343 would make sense if combined
> with a workaround for that issue (although there is no good workaround),
The way to handle it is an autoconf macro (perhaps for AIX/xlc only)
that attempts to compile volatile sig_atomic_t. Possibly followed by
another attempt for plain sig_atomic_t to avoid false positives. Then
we can use the pre-processor to remove volatile. However I don't
really do autoconf, and I don't have access to AIX/xlc either.
I'm tempted simply to put a comment in the code telling AIX/xlc users
how to modify the code.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org