Re: [Freeciv-Dev] (PR#40616) patch: allow 2.1.8 to compile under sun studio community edition 11/08

2009-01-11 Thread James McClain 

http://bugs.freeciv.org/Ticket/Display.html?id=40616 >

Hello,

I did not apply or compile either of these patches, but they appear to be
consistent with our earlier discussions.

Sincerely,
James McClain

On Sat, Jan 10, 2009 at 4:13 AM, Madeline Book wrote:

>
> http://bugs.freeciv.org/Ticket/Display.html?id=40616 >
>
> > [james.mccl...@gmail.com - Thu Jan 01 04:14:04 2009]:
> >
> > Hello,
> >
> > I can confirm that the gtk 2 client does compile smoothly with
> > the patch that you sent applied.  I can also build with the
> > "--enable-debug" and "--enable-client=sdl" versions.  I have
> > not tried the other two.
>
> For completeness here is a version of the patch for trunk too
> (and a minor formatting fix for the S2_1 version).
>
>
> ---
> 機知に富んだ何かがここにあったが、もう出た。
>

Hello,I did not apply or compile either of these patches, but they appear to be consistent with our earlier discussions.Sincerely,James McClainOn Sat, Jan 10, 2009 at 4:13 AM, Madeline Book  wrote:

http://bugs.freeciv.org/Ticket/Display.html?id=40616 >

> [james.mccl...@gmail.com - Thu Jan 01 04:14:04 2009]:
>
> Hello,
>
> I can confirm that the gtk 2 client does compile smoothly with
> the patch that you sent applied.  I can also build with the
> "--enable-debug" and "--enable-client=sdl" versions.  I have
> not tried the other two.

For completeness here is a version of the patch for trunk too
(and a minor formatting fix for the S2_1 version).


---
機知に富んだ何かがここにあったが、もう出た。

___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#40616) patch: allow 2.1.8 to compile under sun studio community edition 11/08

2009-01-09 Thread Madeline Book 

http://bugs.freeciv.org/Ticket/Display.html?id=40616 >

> [james.mccl...@gmail.com - Thu Jan 01 04:14:04 2009]:
> 
> Hello,
> 
> I can confirm that the gtk 2 client does compile smoothly with
> the patch that you sent applied.  I can also build with the
> "--enable-debug" and "--enable-client=sdl" versions.  I have
> not tried the other two.

For completeness here is a version of the patch for trunk too
(and a minor formatting fix for the S2_1 version).


---
機知に富んだ何かがここにあったが、もう出た。
diff --git a/client/gui-gtk-2.0/repodlgs.c b/client/gui-gtk-2.0/repodlgs.c
index 587cd69..bf9c920 100644
--- a/client/gui-gtk-2.0/repodlgs.c
+++ b/client/gui-gtk-2.0/repodlgs.c
@@ -1200,7 +1200,7 @@ void activeunits_report_dialog_update(void)
 {
   struct repoinfo {
 int active_count;
-int upkeep[O_COUNT];
+int upkeep[O_MAX];
 int building_count;
   };
 
diff --git a/client/helpdata.c b/client/helpdata.c
index 7920a58..a781794 100644
--- a/client/helpdata.c
+++ b/client/helpdata.c
@@ -259,39 +259,39 @@ static void insert_allows(struct universal *psource,
   buf[0] = '\0';
 
   /* FIXME: show other data like range and survives. */
-#define COREQ_APPEND(s)			\
-  (coreq_buf[0] != '\0'			\
-   ? cat_snprintf(coreq_buf, sizeof(coreq_buf), Q_("?clistmore:, %s"), (s))  \
-   : sz_strlcpy(coreq_buf, (s)))
 
   improvement_iterate(pimprove) {
 requirement_vector_iterate(&pimprove->reqs, req) {
   if (are_universals_equal(psource, &req->source)) {
-	char coreq_buf[512] = "";
-
-	requirement_vector_iterate(&pimprove->reqs, coreq) {
-	  if (!are_universals_equal(psource, &coreq->source)) {
-	char buf2[512];
-
-	COREQ_APPEND(universal_name_translation(&coreq->source,
-	 buf2, sizeof(buf2)));
-	  }
-	} requirement_vector_iterate_end;
-
-	if (coreq_buf[0] == '\0') {
-	  cat_snprintf(buf, bufsz, _("Allows %s."),
-		   improvement_name_translation(pimprove));
-	} else {
-	  cat_snprintf(buf, bufsz, _("Allows %s (with %s)."),
-		   improvement_name_translation(pimprove),
-		   coreq_buf);
-	}
-	cat_snprintf(buf, bufsz, "\n");
+char coreq_buf[512] = "";
+
+requirement_vector_iterate(&pimprove->reqs, coreq) {
+  if (!are_universals_equal(psource, &coreq->source)) {
+char buf2[512] = "";
+
+universal_name_translation(&coreq->source, buf2,
+   sizeof(buf2));
+if (coreq_buf[0] == '\0') {
+  sz_strlcpy(coreq_buf, buf2);
+} else {
+  cat_snprintf(coreq_buf, sizeof(coreq_buf),
+   Q_("?clistmore:, %s"), buf2);
+}
+  }
+} requirement_vector_iterate_end;
+
+if (coreq_buf[0] == '\0') {
+  cat_snprintf(buf, bufsz, _("Allows %s."),
+   improvement_name_translation(pimprove));
+} else {
+  cat_snprintf(buf, bufsz, _("Allows %s (with %s)."),
+   improvement_name_translation(pimprove),
+   coreq_buf);
+}
+cat_snprintf(buf, bufsz, "\n");
   }
 } requirement_vector_iterate_end;
   } improvement_iterate_end;
-
-#undef COREQ_APPEND
 }
 
 /
diff --git a/client/gui-gtk-2.0/repodlgs.c b/client/gui-gtk-2.0/repodlgs.c
index 7f40ea1..1272966 100644
--- a/client/gui-gtk-2.0/repodlgs.c
+++ b/client/gui-gtk-2.0/repodlgs.c
@@ -1178,7 +1178,7 @@ void activeunits_report_dialog_update(void)
 {
   struct repoinfo {
 int active_count;
-int upkeep[O_COUNT];
+int upkeep[O_MAX];
 int building_count;
   };
 
diff --git a/client/helpdata.c b/client/helpdata.c
index 45850e2..fa8f6be 100644
--- a/client/helpdata.c
+++ b/client/helpdata.c
@@ -237,42 +237,40 @@ static void insert_allows(struct req_source *psource,
   buf[0] = '\0';
 
   /* FIXME: show other data like range and survives. */
-#define COREQ_APPEND(s)			\
-  (coreq_buf[0] != '\0'			\
-   ? cat_snprintf(coreq_buf, sizeof(coreq_buf), Q_("?clistmore:, %s"), (s))  \
-   : sz_strlcpy(coreq_buf, (s)))
-
 
   impr_type_iterate(impr_id) {
 struct impr_type *building = improvement_by_number(impr_id);
 
 requirement_vector_iterate(&building->reqs, req) {
   if (are_req_sources_equal(psource, &req->source)) {
-	char coreq_buf[512] = "";
-
-	requirement_vector_iterate(&building->reqs, coreq) {
-	  if (!are_req_sources_equal(psource, &coreq->source)) {
-	char buf2[512];
-
-	COREQ_APPEND(get_req_source_text(&coreq->source,
-	 buf2, sizeof(buf2)));
-	  }
-	} requirement_vector_iterate_end;
+char coreq_buf[512] = "";
+
+requirement_vector_iterate(&building->reqs, coreq) {
+  if (!are_req_sources_equal(psource, &coreq->source)) {
+char buf2[512] = "";
+
+get_req_source_text(&coreq->source, buf2, sizeof(buf2));
+if (coreq_buf[0] == '\

Re: [Freeciv-Dev] (PR#40616) patch: allow 2.1.8 to compile under sun studio community edition 11/08

2008-12-31 Thread James McClain 

http://bugs.freeciv.org/Ticket/Display.html?id=40616 >

Hello,

I can confirm that the gtk 2 client does compile smoothly with the patch
that you sent applied.  I can also build with the "--enable-debug" and
"--enable-client=sdl" versions.  I have not tried the other two.

Sincerely,
James McClain

On Thu, Jan 1, 2009 at 3:28 AM, Madeline Book wrote:

>
> http://bugs.freeciv.org/Ticket/Display.html?id=40616 >
>
> > [james.mccl...@gmail.com - Thu Jan 01 02:38:33 2009]:
> >
> > That patch that you attached completely fixes the problem
> > with repodlgs.c, but the change to helpdata.c that was in
> > the earlier patch(es) that I sent is also required to make
> > that file compile.
>
> Oh right, sorry I forgot about that. Here's a second
> version of the patch that should fix that problem by
> removing the macro.
>
>
> > Incidentally, I have to say that I do not know for
> > certain that those two fixes are sufficient to make the
> > code compile for any possible configuration.  I have only
> > tried to compile the configuration that comes naturally
> > from the configuration script on my particular computer,
> > so I have not exercised all of the code that is there.
> > In particular, there appear to be a number of different
> > types of clients there, none of which I have looked at
> > other than the gtk one.
>
> Well if you feel like it and have some time to burn,
> you could try compiling with
>
> ./configure --enable-debug
> ./configure --enable-auth (maybe also --with-mysql-prefix)
> ./configure --enable-client=sdl
>
> These would be the main variations of interest to test,
> but it can wait if you have more pressing things to do
> at the moment. ;)
>
>
> ---
> 何なのかしら？
>



-- 
(From Memory Alpha) Doctor Richard Daystrom was one of the most influential
human scientists of the 23rd Century. Daystrom who was born ca. 2219, was
considered a genius in his day, and was compared to such minds as Albert
Einstein, Kazanga and Sitar of Vulcan.

Hello,I can confirm that the gtk 2 client does compile smoothly with the patch that you sent applied.  I can also build with the "--enable-debug" and "--enable-client=sdl" versions.  I have not tried the other two.
Sincerely,James McClainOn Thu, Jan 1, 2009 at 3:28 AM, Madeline Book  wrote:

http://bugs.freeciv.org/Ticket/Display.html?id=40616 >

> [james.mccl...@gmail.com - Thu Jan 01 02:38:33 2009]:
>
> That patch that you attached completely fixes the problem
> with repodlgs.c, but the change to helpdata.c that was in
> the earlier patch(es) that I sent is also required to make
> that file compile.

Oh right, sorry I forgot about that. Here's a second
version of the patch that should fix that problem by
removing the macro.


> Incidentally, I have to say that I do not know for
> certain that those two fixes are sufficient to make the
> code compile for any possible configuration.  I have only
> tried to compile the configuration that comes naturally
> from the configuration script on my particular computer,
> so I have not exercised all of the code that is there.
> In particular, there appear to be a number of different
> types of clients there, none of which I have looked at
> other than the gtk one.

Well if you feel like it and have some time to burn,
you could try compiling with

./configure --enable-debug
./configure --enable-auth (maybe also --with-mysql-prefix)
./configure --enable-client=sdl

These would be the main variations of interest to test,
but it can wait if you have more pressing things to do
at the moment. ;)


---
何なのかしら？
-- (From Memory Alpha) Doctor Richard Daystrom was one of the most influential human scientists of the 23rd Century. Daystrom who was born ca. 2219, was considered a genius in his day, and was compared to such minds as Albert Einstein, Kazanga and Sitar of Vulcan.

___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#40616) patch: allow 2.1.8 to compile under sun studio community edition 11/08

2008-12-31 Thread James McClain 

http://bugs.freeciv.org/Ticket/Display.html?id=40616 >

Hello,

Yeah, it is kind of interesting to see some of subtle differences in
compilers like that.  As you mentioned, googling some of the error messages
does seem to show that this is an issue which is not particular to this one
program.

That patch that you attached completely fixes the problem with repodlgs.c,
but the change to helpdata.c that was in the earlier patch(es) that I sent
is also required to make that file compile.

Incidentally, I have to say that I do not know for certain that those two
fixes are sufficient to make the code compile for any possible
configuration.  I have only tried to compile the configuration that comes
naturally from the configuration script on my particular computer, so I have
not exercised all of the code that is there.  In particular, there appear to
be a number of different types of clients there, none of which I have looked
at other than the gtk one.

Thank you,
James McClain

On Thu, Jan 1, 2009 at 12:13 AM, Madeline Book wrote:

>
> http://bugs.freeciv.org/Ticket/Display.html?id=40616 >
>
> > [james.mccl...@gmail.com - Wed Dec 31 22:12:35 2008]:
> >
> > Using O_MAX rather than O_COUNT does work.  Moving the definition
> > out of the function into file scope does not work..
>
> Interesting. So I assume the attached patch completely fixes
> the compilation problems?
>
>
> ---
> ですが、全然分かりません。
>
>


-- 
(From Memory Alpha) Doctor Richard Daystrom was one of the most influential
human scientists of the 23rd Century. Daystrom who was born ca. 2219, was
considered a genius in his day, and was compared to such minds as Albert
Einstein, Kazanga and Sitar of Vulcan.

Hello,Yeah, it is kind of interesting to see some of subtle differences in compilers like that.  As you mentioned, googling some of the error messages does seem to show that this is an issue which is not particular to this one program.
That patch that you attached completely fixes the problem with repodlgs.c, but the change to helpdata.c that was in the earlier patch(es) that I sent is also required to make that file compile.Incidentally, I have to say that I do not know for certain that those two fixes are sufficient to make the code compile for any possible configuration.  I have only tried to compile the configuration that comes naturally from the configuration script on my particular computer, so I have not exercised all of the code that is there.  In particular, there appear to be a number of different types of clients there, none of which I have looked at other than the gtk one.
Thank you,James McClainOn Thu, Jan 1, 2009 at 12:13 AM, Madeline Book  wrote:

http://bugs.freeciv.org/Ticket/Display.html?id=40616 >

> [james.mccl...@gmail.com - Wed Dec 31 22:12:35 2008]:
>
> Using O_MAX rather than O_COUNT does work.  Moving the definition
> out of the function into file scope does not work..

Interesting. So I assume the attached patch completely fixes
the compilation problems?


---
ですが、全然分かりません。

-- (From Memory Alpha) Doctor Richard Daystrom was one of the most influential human scientists of the 23rd Century. Daystrom who was born ca. 2219, was considered a genius in his day, and was compared to such minds as Albert Einstein, Kazanga and Sitar of Vulcan.

___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#40616) patch: allow 2.1.8 to compile under sun studio community edition 11/08

2008-12-31 Thread Madeline Book 

http://bugs.freeciv.org/Ticket/Display.html?id=40616 >

> [james.mccl...@gmail.com - Thu Jan 01 02:38:33 2009]:
> 
> That patch that you attached completely fixes the problem
> with repodlgs.c, but the change to helpdata.c that was in
> the earlier patch(es) that I sent is also required to make
> that file compile.

Oh right, sorry I forgot about that. Here's a second
version of the patch that should fix that problem by
removing the macro.


> Incidentally, I have to say that I do not know for
> certain that those two fixes are sufficient to make the
> code compile for any possible configuration.  I have only
> tried to compile the configuration that comes naturally
> from the configuration script on my particular computer,
> so I have not exercised all of the code that is there.
> In particular, there appear to be a number of different
> types of clients there, none of which I have looked at
> other than the gtk one.

Well if you feel like it and have some time to burn,
you could try compiling with

./configure --enable-debug
./configure --enable-auth (maybe also --with-mysql-prefix)
./configure --enable-client=sdl

These would be the main variations of interest to test,
but it can wait if you have more pressing things to do
at the moment. ;)


---
何なのかしら？
diff --git a/client/gui-gtk-2.0/repodlgs.c b/client/gui-gtk-2.0/repodlgs.c
index 7f40ea1..1272966 100644
--- a/client/gui-gtk-2.0/repodlgs.c
+++ b/client/gui-gtk-2.0/repodlgs.c
@@ -1178,7 +1178,7 @@ void activeunits_report_dialog_update(void)
 {
   struct repoinfo {
 int active_count;
-int upkeep[O_COUNT];
+int upkeep[O_MAX];
 int building_count;
   };
 
diff --git a/client/helpdata.c b/client/helpdata.c
index 45850e2..2071502 100644
--- a/client/helpdata.c
+++ b/client/helpdata.c
@@ -237,42 +237,40 @@ static void insert_allows(struct req_source *psource,
   buf[0] = '\0';
 
   /* FIXME: show other data like range and survives. */
-#define COREQ_APPEND(s)			\
-  (coreq_buf[0] != '\0'			\
-   ? cat_snprintf(coreq_buf, sizeof(coreq_buf), Q_("?clistmore:, %s"), (s))  \
-   : sz_strlcpy(coreq_buf, (s)))
-
 
   impr_type_iterate(impr_id) {
 struct impr_type *building = improvement_by_number(impr_id);
 
 requirement_vector_iterate(&building->reqs, req) {
   if (are_req_sources_equal(psource, &req->source)) {
-	char coreq_buf[512] = "";
-
-	requirement_vector_iterate(&building->reqs, coreq) {
-	  if (!are_req_sources_equal(psource, &coreq->source)) {
-	char buf2[512];
-
-	COREQ_APPEND(get_req_source_text(&coreq->source,
-	 buf2, sizeof(buf2)));
-	  }
-	} requirement_vector_iterate_end;
+char coreq_buf[512] = "";
+
+requirement_vector_iterate(&building->reqs, coreq) {
+  if (!are_req_sources_equal(psource, &coreq->source)) {
+char buf2[512] = "";
+
+get_req_source_text(&coreq->source, buf2, sizeof(buf2));
+if (coreq_buf[0] == '\0') {
+  sz_strlcpy(coreq_buf, buf2);
+} else {
+  cat_snprintf(coreq_buf, sizeof(coreq_buf),
+   Q_("?clistmore:, %s"), buf2);
+}
+  }
+} requirement_vector_iterate_end;
 
 	if (coreq_buf[0] == '\0') {
-	  cat_snprintf(buf, bufsz, _("Allows %s."),
-		   improvement_name_translation(impr_id));
-	} else {
-	  cat_snprintf(buf, bufsz, _("Allows %s (with %s)."),
-		   improvement_name_translation(impr_id),
-		   coreq_buf);
-	}
-	cat_snprintf(buf, bufsz, "\n");
+  cat_snprintf(buf, bufsz, _("Allows %s."),
+   improvement_name_translation(impr_id));
+} else {
+  cat_snprintf(buf, bufsz, _("Allows %s (with %s)."),
+   improvement_name_translation(impr_id),
+   coreq_buf);
+}
+cat_snprintf(buf, bufsz, "\n");
   }
 } requirement_vector_iterate_end;
   } impr_type_iterate_end;
-
-#undef COREQ_APPEND
 }
 
 /
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#40616) patch: allow 2.1.8 to compile under sun studio community edition 11/08

2008-12-31 Thread Madeline Book 

http://bugs.freeciv.org/Ticket/Display.html?id=40616 >

> [james.mccl...@gmail.com - Wed Dec 31 22:12:35 2008]:
> 
> Using O_MAX rather than O_COUNT does work.  Moving the definition
> out of the function into file scope does not work..

Interesting. So I assume the attached patch completely fixes
the compilation problems?


---
ですが、全然分かりません。

diff --git a/client/gui-gtk-2.0/repodlgs.c b/client/gui-gtk-2.0/repodlgs.c
index 7f40ea1..1272966 100644
--- a/client/gui-gtk-2.0/repodlgs.c
+++ b/client/gui-gtk-2.0/repodlgs.c
@@ -1178,7 +1178,7 @@ void activeunits_report_dialog_update(void)
 {
   struct repoinfo {
 int active_count;
-int upkeep[O_COUNT];
+int upkeep[O_MAX];
 int building_count;
   };
 
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#40616) patch: allow 2.1.8 to compile under sun studio community edition 11/08

2008-12-31 Thread James McClain 

http://bugs.freeciv.org/Ticket/Display.html?id=40616 >

Hello,

Using O_MAX rather than O_COUNT does work.  Moving the definition out of the
function into file scope does not work..

Sincerely,
James McClain

On Wed, Dec 31, 2008 at 9:14 PM, Madeline Book wrote:

>
> http://bugs.freeciv.org/Ticket/Display.html?id=40616 >
>
> Thank you for the explanations and the error message output,
> that makes the situation somewhat clearer.
>
> I still suspect that the problem lies in the definition of
> 'struct repoinfo'. Can you please try moving it outside the
> scope of activeunits_report_dialog_update() (i.e. into file
> scope), and seeing if that fixes the problem? Also, try
> O_MAX instead of O_COUNT.
>
> Failling that, O_COUNT could be defined to a literal numeric
> constant (i.e. 6), or the 'upkeep' field in repoinfo renamed.
>
> Searching for that error message on the web yields a bunch
> of pages that seem to imply it is due to a bug in the sun
> compiler. The fact that somehow the compiler gets confused
> with the "int upkeep;" in 'struct packet_ruleset_building'
> in common/packets_gen.h would also suggest this.
>
>
> ---
> 一等賞はとても素敵ですね。
>
>
>


-- 
(From Memory Alpha) Doctor Richard Daystrom was one of the most influential
human scientists of the 23rd Century. Daystrom who was born ca. 2219, was
considered a genius in his day, and was compared to such minds as Albert
Einstein, Kazanga and Sitar of Vulcan.

Hello,Using O_MAX rather than O_COUNT does work.  Moving the definition out of the function into file scope does not work..Sincerely,James McClainOn Wed, Dec 31, 2008 at 9:14 PM, Madeline Book  wrote:

http://bugs.freeciv.org/Ticket/Display.html?id=40616 >

Thank you for the explanations and the error message output,
that makes the situation somewhat clearer.

I still suspect that the problem lies in the definition of
'struct repoinfo'. Can you please try moving it outside the
scope of activeunits_report_dialog_update() (i.e. into file
scope), and seeing if that fixes the problem? Also, try
O_MAX instead of O_COUNT.

Failling that, O_COUNT could be defined to a literal numeric
constant (i.e. 6), or the 'upkeep' field in repoinfo renamed.

Searching for that error message on the web yields a bunch
of pages that seem to imply it is due to a bug in the sun
compiler. The fact that somehow the compiler gets confused
with the "int upkeep;" in 'struct packet_ruleset_building'
in common/packets_gen.h would also suggest this.


---
一等賞はとても素敵ですね。


-- (From Memory Alpha) Doctor Richard Daystrom was one of the most influential human scientists of the 23rd Century. Daystrom who was born ca. 2219, was considered a genius in his day, and was compared to such minds as Albert Einstein, Kazanga and Sitar of Vulcan.

___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#40616) patch: allow 2.1.8 to compile under sun studio community edition 11/08

2008-12-31 Thread Madeline Book 

http://bugs.freeciv.org/Ticket/Display.html?id=40616 >

Thank you for the explanations and the error message output,
that makes the situation somewhat clearer.

I still suspect that the problem lies in the definition of
'struct repoinfo'. Can you please try moving it outside the
scope of activeunits_report_dialog_update() (i.e. into file
scope), and seeing if that fixes the problem? Also, try
O_MAX instead of O_COUNT.

Failling that, O_COUNT could be defined to a literal numeric
constant (i.e. 6), or the 'upkeep' field in repoinfo renamed.

Searching for that error message on the web yields a bunch
of pages that seem to imply it is due to a bug in the sun
compiler. The fact that somehow the compiler gets confused
with the "int upkeep;" in 'struct packet_ruleset_building'
in common/packets_gen.h would also suggest this.


---
一等賞はとても素敵ですね。



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#40616) patch: allow 2.1.8 to compile under sun studio community edition 11/08

2008-12-31 Thread James McClain 

http://bugs.freeciv.org/Ticket/Display.html?id=40616 >

This transaction appears to have no content
Hello,

Please let me take a step back from the patch that I sent before.  I have
attached smaller one to this email.  I will explain in detail what it does.

Essentially, the patch just allows freeciv 2.1.8 to be compiled with the sun
studio 11/08 compiler.  There seem to be some differences in C99 compliance
between sun studio and gcc.  The file client/gui-gtk-2.0/repodlgs.c contains
defines the size of an array called upkeep in terms of O_COUNT.  I may be
incorrect, but O_COUNT seems to be field of an enumeration.  The sun studio
compiler considers this to be variable and will therefore not allow it be
used as the size of a variable array, while gcc considers it fixed and
therefore does.  The change to that file simply uses and integer for the
size.  The error message which comes out of the sun studio compiler with the
unpatched file is:

source='repodlgs.c' object='repodlgs.o' libtool=no \
depfile='/repodlgs.Po' tmpdepfile='/repodlgs.TPo' \
depmode=none /bin/sh ../../bootstrap/depcomp \
/opt/sun/sunstudioceres/bin/cc -DHAVE_CONFIG_H -I. -I. -I../..  -I.
-I./.. -I./../include -I../../utility -I../../common -I../../common/aicore
-I../../intl -I./../agents -I/usr/include/gtk-2.0
-I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng12
-DLOCALEDIR="\"/home/jmcclain/freeciv/share/locale\""
-DDEFAULT_DATA_PATH="\".:data:~/.freeciv:/home/jmcclain/freeciv/share/freeciv\""
-O3 -native -xchar=signed -c `test -f 'repodlgs.c' || echo './'`repodlgs.c
"../../common/packets_gen.h", line 929: member can not have variably
modified type: upkeep
"repodlgs.c", line 1204: cannot dereference non-pointer type
"repodlgs.c", line 1228: cannot dereference non-pointer type
"repodlgs.c", line 1229: cannot dereference non-pointer type
"repodlgs.c", line 1230: cannot dereference non-pointer type
"repodlgs.c", line 1243: cannot dereference non-pointer type
"repodlgs.c", line 1243: cannot dereference non-pointer type
"repodlgs.c", line 1254: cannot dereference non-pointer type
"repodlgs.c", line 1255: cannot dereference non-pointer type
"repodlgs.c", line 1256: cannot dereference non-pointer type
cc: acomp failed for repodlgs.c

All of those lines about not being able to dereference non-pointer types are
lines on which arrays called "upkeep" are used -- the compiler seems to have
been confused by the earlier and unrelated declaration of an array called
upkeep (which is fixed by the attached patch).

The change to client/helpdata.c is because of another peculiarity in this
particular compiler.  For the "? : " construct, the compiler expects the
things on both sides of the ":" to be of the same type (another issue of
strictness).  Because the thing on the right of the colon is a macro which
is explicity cast to void and the thing on the left has type int, there is a
mis-match.  My patch simply explicity casts the thing on the left to type
void.

As as regards the #if 's: I understand that those are not acceptable for
inclusion.  Those are there in the event that you or others wanted to apply
the patch then condition the changes on some macro defined by the
configuration system.

Sorry for not explaining more fully before.

Sincerely,
James McClain

On Wed, Dec 31, 2008 at 7:08 PM, Madeline Book wrote:

>
> http://bugs.freeciv.org/Ticket/Display.html?id=40616 >
>
> > [james.mccl...@gmail.com - Wed Dec 31 01:55:26 2008]:
> >
> > This email contains a patch that allows version 2.1.8 of
> > FreeCiv to compile under the 11/08 version (the latest
> > I believe) version of the Sun Studio Community Edition
> > compiler. The patch seems to produce working executables
> > on the AMD64 version of OpenSUSE 11.1 with the compiler
> > mentioned above.  The changes are all minor ones which
> > have to do with differences in implementation of the C99
> > standard between the Sun Studio compiler and gcc.
>
> I don't understand the purpose of the changes in your patch;
> what are the errors returned by the compiler for the existing
> code? And where can I find a c99 implementation status page
> for the "sun studio compiler" (for example, like the gcc one:
> http://gcc.gnu.org/c99status.html)?
>
> The main c99 feature in use in the freeciv code is variable
> length arrays (i.e. arrays allocated on the stack); most
> other c99 uses can be rephrased to equivalent c expressions,
> I would hope.
>
> Also I don't agree with the way your patch changes the code.
> If anything the #if should be on the compiler version, and
> not "#if 0" or "#if 1". The way upkeep_ptr is used is very
> unattractive. Why does it have to be a global variable, why
> not just declare it in the scope of the function? Why does
> it have to be a pointer anyway?
>
> Is it the 'struct repoinfo' definition within

[Freeciv-Dev] (PR#40616) patch: allow 2.1.8 to compile under sun studio community edition 11/08

2008-12-31 Thread Madeline Book 

http://bugs.freeciv.org/Ticket/Display.html?id=40616 >

> [james.mccl...@gmail.com - Wed Dec 31 01:55:26 2008]:
>
> This email contains a patch that allows version 2.1.8 of
> FreeCiv to compile under the 11/08 version (the latest
> I believe) version of the Sun Studio Community Edition
> compiler. The patch seems to produce working executables
> on the AMD64 version of OpenSUSE 11.1 with the compiler
> mentioned above.  The changes are all minor ones which
> have to do with differences in implementation of the C99
> standard between the Sun Studio compiler and gcc.

I don't understand the purpose of the changes in your patch;
what are the errors returned by the compiler for the existing
code? And where can I find a c99 implementation status page
for the "sun studio compiler" (for example, like the gcc one:
http://gcc.gnu.org/c99status.html)?

The main c99 feature in use in the freeciv code is variable
length arrays (i.e. arrays allocated on the stack); most
other c99 uses can be rephrased to equivalent c expressions,
I would hope.

Also I don't agree with the way your patch changes the code.
If anything the #if should be on the compiler version, and
not "#if 0" or "#if 1". The way upkeep_ptr is used is very
unattractive. Why does it have to be a global variable, why
not just declare it in the scope of the function? Why does
it have to be a pointer anyway?

Is it the 'struct repoinfo' definition within the function
activeunits_report_dialog_update() that is causing the
compiler to choke? Why not just move it out then? Since
there are plently of uses of

struct foo { int array[A_CONSTANT]; };

elsewhere in the code. Maybe it is the type of 'O_COUNT'
that is messing it up? So make it a macro or just use
O_LAST. (Where do you even get 0x20 from?)

I find it hard to believe that your compiler would accept

> upkeep_ptr = &(unitarray[unit_type(punit)->index].upkeep);
> *(upkeep_ptr + o) += punit->upkeep[o];

but not

> unitarray[unit_type(punit)->index].upkeep[o] += punit->upkeep[o];

What part of either expression is specific to c99? I would
guess that this kind of code occurs in numerous other places
as well, yet it only causes compilation problems here? :(


>  #define COREQ_APPEND(s) \
>(coreq_buf[0] != '\0' \
> -   ? cat_snprintf(coreq_buf, sizeof(coreq_buf), Q_("?clistmore:,
> %s"), (s))  \
> +   ? (void)cat_snprintf(coreq_buf, sizeof(coreq_buf),
> Q_("?clistmore:, %s"), (s)) \
> : sz_strlcpy(coreq_buf, (s)))

This macro is hideous already, and should at least be made
into an inline function.


---
競技に参加するつもりですか？

___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#40616) patch: allow 2.1.8 to compile under sun studio community edition 11/08

2008-12-31 Thread James McClain 

http://bugs.freeciv.org/Ticket/Display.html?id=40616 >

diff -ru freeciv-2.1.8/client/gui-gtk-2.0/repodlgs.c 
/home/person/src/freeciv-2.1.8/client/gui-gtk-2.0/repodlgs.c
--- freeciv-2.1.8/client/gui-gtk-2.0/repodlgs.c 2008-11-30 12:53:30.0 
+
+++ /home/person/src/freeciv-2.1.8/client/gui-gtk-2.0/repodlgs.c
2008-12-31 01:24:36.0 +
@@ -118,6 +118,8 @@
 
 #define NUM_SCORE_COLS 14
 
+int * upkeep_ptr;
+
 /**/
 static GtkWidget *settable_options_dialog_shell;
 
@@ -1178,7 +1180,11 @@
 {
   struct repoinfo {
 int active_count;
+#if 0
 int upkeep[O_COUNT];
+#else
+int upkeep[0x20];
+#endif
 int building_count;
   };
 
@@ -1201,7 +1207,12 @@
   (unitarray[unit_type(punit)->index].active_count)++;
   if (punit->homecity) {
output_type_iterate(o) {
+#if 0
  unitarray[unit_type(punit)->index].upkeep[o] += punit->upkeep[o];
+#else
+ upkeep_ptr = &(unitarray[unit_type(punit)->index].upkeep);
+ *(upkeep_ptr + o) += punit->upkeep[o];
+#endif
} output_type_iterate_end;
   }
 } unit_list_iterate_end;
@@ -1218,6 +1229,9 @@
   Unit_type_id uti = punittype->index;
   if (unitarray[uti].active_count > 0
  || unitarray[uti].building_count > 0) {
+#if 1
+   upkeep_ptr = &(unitarray[uti].upkeep);
+#endif
can = (can_upgrade_unittype(game.player_ptr, punittype) != NULL);

 gtk_list_store_append(activeunits_store, &it);
@@ -1225,9 +1239,15 @@
1, can,
2, unitarray[uti].building_count,
3, unitarray[uti].active_count,
+#if 0
4, unitarray[uti].upkeep[O_SHIELD],
5, unitarray[uti].upkeep[O_FOOD],
6, unitarray[uti].upkeep[O_GOLD],
+#else
+   4, *(upkeep_ptr + O_SHIELD),
+   5, *(upkeep_ptr + O_FOOD),
+   6, *(upkeep_ptr + O_GOLD),
+#endif
7, TRUE,
8, ((unitarray[uti].active_count > 0)
? uti : U_LAST),
@@ -1240,20 +1260,37 @@
k++;
unittotals.active_count += unitarray[uti].active_count;
output_type_iterate(o) {
+ #if 0
  unittotals.upkeep[o] += unitarray[uti].upkeep[o];
+ #else
+ int * upkeep_ptr2;
+
+ upkeep_ptr = &(unittotals.upkeep);
+ upkeep_ptr2 = &(unitarray[uti].upkeep);
+ *(upkeep_ptr + o) += *(upkeep_ptr2 + o);
+ #endif
} output_type_iterate_end;
unittotals.building_count += unitarray[uti].building_count;
   }
 } unit_type_iterate_end;
 
 gtk_list_store_append(activeunits_store, &it);
+#if 1
+upkeep_ptr = &(unittotals.upkeep);
+#endif
 gtk_list_store_set(activeunits_store, &it,
1, FALSE,
2, unittotals.building_count,
3, unittotals.active_count,
+#if 0
4, unittotals.upkeep[O_SHIELD],
5, unittotals.upkeep[O_FOOD],
6, unittotals.upkeep[O_GOLD],
+#else
+   4, *(upkeep_ptr + O_SHIELD),
+   5, *(upkeep_ptr + O_FOOD),
+   6, *(upkeep_ptr + O_GOLD),
+#endif
7, FALSE,
8, U_LAST, -1);
 g_value_init(&value, G_TYPE_STRING);
diff -ru freeciv-2.1.8/client/helpdata.c 
/home/person/src/freeciv-2.1.8/client/helpdata.c
--- freeciv-2.1.8/client/helpdata.c 2008-11-30 12:54:04.0 +
+++ /home/person/src/freeciv-2.1.8/client/helpdata.c2008-12-31 
01:29:53.0 +
@@ -239,7 +239,7 @@
   /* FIXME: show other data like range and survives. */
 #define COREQ_APPEND(s)
\
   (coreq_buf[0] != '\0'
\
-   ? cat_snprintf(coreq_buf, sizeof(coreq_buf), Q_("?clistmore:, %s"), (s))  \
+   ? (void)cat_snprintf(coreq_buf, sizeof(coreq_buf), Q_("?clistmore:, %s"), 
(s)) \
: sz_strlcpy(coreq_buf, (s)))
 
 

Hello,

This email contains a patch that allows version 2.1.8 of FreeCiv to compile
under the 11/08 version (the latest I believe) version of the Sun Studio
Community Edition compiler.  The patch seems to produce working executables
on the AMD64 version of OpenSUSE 11.1 with the compiler mentioned above.
The changes are all minor ones which have to do with differences in
implementation of the C99 standard between the Sun Studio compiler and gcc.

Also, I noticed that there are several clients there, but the only one that
I have changed is the gtk 2.0 one.  If there is interest, I suppose I could
change the others.

Thank you,
James McClain
Hello,This email contains a patch that allows version 2.1.8 of FreeCiv to compile under the 11/08 version (the latest I believe) version of the Sun Studio Community Edition compiler.  The patch seems to produce working executables on the AMD64 version of OpenSUSE 11.1 with the compiler mentioned above.  The changes are all minor ones whi