Bug#652599: [php-maint] Bug#652599: php5: use_embedded_timezonedb.patch causes ext/date/lib/parse_tz.c to fail to compile

January 31st, 2012 - 06:00 pm ET by Dominic Scheirlinck | Report spam

It compiles correctly for me



Are you certain you had both the quilt patch applied and HAVE_SYSTEM_TZDATA undefined? What did you pass in for '--with-system-tzdata' to configure? Or did you unset HAVE_SYSTEM_TZDATA in some other way?

I double-checked the state of the patched ext/date/lib/parse_tz.c in 5.3.9-5, and it appeared the same as in my original pastebin: the preprocessor directives are still in the same place. So, I don't understand how it could possibly work for you: it seems to produce invalid C from the preprocessor stage.

To show that, here's another pastebin, this time the result of running gcc -E ext/date/lib/parse_tz.c, which should just do the preprocessing: http://paste.debian.net/154235/ - note the hanging else clause.


What is your build environment?



# uname -a
Linux dominic-vm-lucid 2.6.32-36-server #79-Ubuntu SMP Tue Nov 8 22:44:38 UTC 2011 x86_64 GNU/Linux
# gcc -v
Target: x86_64-linux-gnu
[…]
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)

What else would you like to know? I'm pretty sure this is unrelated to my environment. To be clear: I'm not saying it happens with a normal build (because most people building the package will want to use system TZ data), but it's still a bug that affects the few people (I assume) who don't.

Dom


To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
email Follow the discussionReplies 7 repliesReplies Make a reply

Similar topics

Replies

#1 Ondřej Surý
January 31st, 2012 - 07:40 pm ET | Report spam
severity 652599 wishlist
thank you

Ah, didn't catch that you are using modified build. In that case you
are on your own,
we only support our configure options and our build environment.

But if you provide a clean patch to fix the issue, I'll apply it in
the git and it will be part
of some next release.

O.


On Tue, Jan 31, 2012 at 23:46, Dominic Scheirlinck wrote:
It compiles correctly for me



Are you certain you had both the quilt patch applied and HAVE_SYSTEM_TZDATA undefined? What did you pass in for '--with-system-tzdata' to configure? Or did you unset HAVE_SYSTEM_TZDATA in some other way?

I double-checked the state of the patched ext/date/lib/parse_tz.c in 5.3.9-5, and it appeared the same as in my original pastebin: the preprocessor directives are still in the same place. So, I don't understand how it could possibly work for you: it seems to produce invalid C from the preprocessor stage.

To show that, here's another pastebin, this time the result of running gcc -E ext/date/lib/parse_tz.c, which should just do the preprocessing: http://paste.debian.net/154235/ - note the hanging else clause.

What is your build environment?



# uname -a
Linux dominic-vm-lucid 2.6.32-36-server #79-Ubuntu SMP Tue Nov 8 22:44:38 UTC 2011 x86_64 GNU/Linux
# gcc -v
Target: x86_64-linux-gnu
[…]
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)

What else would you like to know? I'm pretty sure this is unrelated to my environment. To be clear: I'm not saying it happens with a normal build (because most people building the package will want to use system TZ data), but it's still a bug that affects the few people (I assume) who don't.

Dom


_______________________________________________
pkg-php-maint mailing list

http://lists.alioth.debian.org/cgi-...-php-maint





Ondřej Surý



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Replies Reply to this message
#2 Dominic Scheirlinck
January 31st, 2012 - 10:10 pm ET | Report spam

Two files attached (this time):

* fix_use_embedded_timezonedb.patch is a patch that fixes the issue.
It acts directly on the .c file, and should be applied after
use_embedded_timezonedb.patch in the quilt series.
 * use_embedded_timezonedb.patch.patch is a patch for
use_embedded_timezonedb.patch. It acts on the original patch and fixes
it that way.

Dom

On Wed, Feb 1, 2012 at 1:36 PM, Ondřej Surའwrote:
severity 652599 wishlist
thank you

Ah, didn't catch that you are using modified build. In that case you
are on your own,
we only support our configure options and our build environment.

But if you provide a clean patch to fix the issue, I'll apply it in
the git and it will be part
of some next release.

O.


On Tue, Jan 31, 2012 at 23:46, Dominic Scheirlinck wrote:
It compiles correctly for me



Are you certain you had both the quilt patch applied and HAVE_SYSTEM_TZDATA undefined? What did you pass in for '--with-system-tzdata' to configure? Or did you unset HAVE_SYSTEM_TZDATA in some other way?

I double-checked the state of the patched ext/date/lib/parse_tz.c in 5.3.9-5, and it appeared the same as in my original pastebin: the preprocessor directives are still in the same place. So, I don't understand how it could possibly work for you: it seems to produce invalid C from the preprocessor stage.

To show that, here's another pastebin, this time the result of running gcc -E ext/date/lib/parse_tz.c, which should just do the preprocessing: http://paste.debian.net/154235/ - note the hanging else clause.

What is your build environment?



# uname -a
Linux dominic-vm-lucid 2.6.32-36-server #79-Ubuntu SMP Tue Nov 8 22:44:38 UTC 2011 x86_64 GNU/Linux
# gcc -v
Target: x86_64-linux-gnu
[…]
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)

What else would you like to know? I'm pretty sure this is unrelated to my environment. To be clear: I'm not saying it happens with a normal build (because most people building the package will want to use system TZ data), but it's still a bug that affects the few people (I assume) who don't.

Dom


_______________________________________________
pkg-php-maint mailing list

http://lists.alioth.debian.org/cgi-...-php-maint





Ondřej Surà½



name="use_embedded_timezonedb.patch.patch"
filename="use_embedded_timezonedb.patch.patch"
X-Attachment-Id: f_gy3rrwxf0

LS0tIHVzZV9lbWJlZGRlZF90aW1lem9uZWRiLnBhdGNoLmEJMjAxMi0wMi0wMSAxNTo1MTozNC4z
NjQzODc4MTggKzEzMDAKKysrIHVzZV9lbWJlZGRlZF90aW1lem9uZWRiLnBhdGNoLmIJMjAxMi0w
Mi0wMSAxNTo1NToyMS40MjQzNjQ5OTQgKzEzMDAKQEAgLTYyNCw5ICs2MjQsOSBAQAogKwogKwkJ
CS8qIE5vdyBkb25lIHdpdGggdGhlIG1tYXAgc2VnbWVudCAtIGRpc2NhcmQgaXQuICovCiArCQkJ
bXVubWFwKG1lbW1hcCwgbWFwbGVuKTsKKysJCX0gZWxzZQogKyNlbmRpZgotKwkJfQotKwkJZWxz
ZSB7CisrCQl7CiArCQkJLyogUEhQLXN0eWxlIC0gdXNlIHRoZSBlbWJlZGRlZCBpbmZvLiAqLwog
KwkJCXJlYWRfbG9jYXRpb24oJnR6ZiwgdG1wKTsKICsJCX0K
name="fix_use_embedded_timezonedb.patch"
filename="fix_use_embedded_timezonedb.patch"
X-Attachment-Id: f_gy3rshfu1

VG8gYmUgYXBwbGllZCBhZnRlciB1c2VfZW1iZWRkZWRfdGltZXpvbmVkYi5wYXRjaAoKPT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PQotLS0gYS9leHQvZGF0ZS9saWIvcGFyc2VfdHouYwkyMDExLTEyLTE5IDE1OjAyOjU3LjI5
NDk5MTg2MSArMTMwMAorKysgYi9leHQvZGF0ZS9saWIvcGFyc2VfdHouYwkyMDExLTEyLTE5IDE1
OjA2OjQyLjI4NDk3MDEyOCArMTMwMApAQCAtODY2LDkgKzg2Niw5IEBACiAKIAkJCS8qIE5vdyBk
b25lIHdpdGggdGhlIG1tYXAgc2VnbWVudCAtIGRpc2NhcmQgaXQuICovCiAJCQltdW5tYXAobWVt
bWFwLCBtYXBsZW4pOworCQl9IGVsc2UKICNlbmRpZgotCQl9Ci0JCWVsc2UgeworCQl7CiAJCQkv
KiBQSFAtc3R5bGUgLSB1c2UgdGhlIGVtYmVkZGVkIGluZm8uICovCiAJCQlyZWFkX2xvY2F0aW9u
KCZ0emYsIHRtcCk7CiAJCX0K



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Replies Reply to this message
#3 Ondřej Surý
February 01st, 2012 - 02:50 am ET | Report spam
Perfect, applied the later one.

Thanks that was very helpful,
Ondrej

On Wed, Feb 1, 2012 at 04:01, Dominic Scheirlinck wrote:
Two files attached (this time):

 * fix_use_embedded_timezonedb.patch is a patch that fixes the issue.
It acts directly on the .c file, and should be applied after
use_embedded_timezonedb.patch in the quilt series.
 * use_embedded_timezonedb.patch.patch is a patch for
use_embedded_timezonedb.patch. It acts on the original patch and fixes
it that way.

Dom

On Wed, Feb 1, 2012 at 1:36 PM, Ondřej Surý wrote:
severity 652599 wishlist
thank you

Ah, didn't catch that you are using modified build. In that case you
are on your own,
we only support our configure options and our build environment.

But if you provide a clean patch to fix the issue, I'll apply it in
the git and it will be part
of some next release.

O.


On Tue, Jan 31, 2012 at 23:46, Dominic Scheirlinck wrote:
It compiles correctly for me



Are you certain you had both the quilt patch applied and HAVE_SYSTEM_TZDATA undefined? What did you pass in for '--with-system-tzdata' to configure? Or did you unset HAVE_SYSTEM_TZDATA in some other way?

I double-checked the state of the patched ext/date/lib/parse_tz.c in 5.3.9-5, and it appeared the same as in my original pastebin: the preprocessor directives are still in the same place. So, I don't understand how it could possibly work for you: it seems to produce invalid C from the preprocessor stage.

To show that, here's another pastebin, this time the result of running gcc -E ext/date/lib/parse_tz.c, which should just do the preprocessing: http://paste.debian.net/154235/ - note the hanging else clause.

What is your build environment?



# uname -a
Linux dominic-vm-lucid 2.6.32-36-server #79-Ubuntu SMP Tue Nov 8 22:44:38 UTC 2011 x86_64 GNU/Linux
# gcc -v
Target: x86_64-linux-gnu
[…]
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)

What else would you like to know? I'm pretty sure this is unrelated to my environment. To be clear: I'm not saying it happens with a normal build (because most people building the package will want to use system TZ data), but it's still a bug that affects the few people (I assume) who don't.

Dom


_______________________________________________
pkg-php-maint mailing list

http://lists.alioth.debian.org/cgi-...-php-maint





Ondřej Surý







Ondřej Surý



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Replies Reply to this message
#4 sean finney
February 01st, 2012 - 11:10 am ET | Report spam
On Wed, Feb 01, 2012 at 01:36:31AM +0100, Ondřej Surý wrote:
But if you provide a clean patch to fix the issue, I'll apply it in
the git and it will be part
of some next release.



We should make sure to bring the system tzdata patch author (Joe) into
the conversation as well. Maybe he's updated it already?

@Joe: Are you aware of the issue (compile failures when the sys tzdata
is applied but HAVE_SYSTEM_TZDATA is undefined)? We're using r7
of the patch, fwiw.


Sean



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Replies Reply to this message
#5 Ondřej Surý
February 01st, 2012 - 11:20 am ET | Report spam
I have just checked Fedora packages few days ago, since I was pulling
some other patches and Fedora still have v7 (unless there was a silent
change).

But hey you're right, Joe should be informed.

Thanks,
O.

2012/2/1 sean finney :
On Wed, Feb 01, 2012 at 01:36:31AM +0100, Ondřej Surý wrote:
But if you provide a clean patch to fix the issue, I'll apply it in
the git and it will be part
of some next release.



We should make sure to bring the system tzdata patch author (Joe) into
the conversation as well.  Maybe he's updated it already?

@Joe: Are you aware of the issue (compile failures when the sys tzdata
     is applied but HAVE_SYSTEM_TZDATA is undefined)?  We're using r7
     of the patch, fwiw.


         Sean





Ondřej Surý



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Replies Reply to this message
Help Create a new topicNext page Replies Make a reply
Search Make your own search