zunger-humu commented 4 years ago

pip install is failing with this:

    x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fstack-protector-strong -g -Wformat -Werror=format-security -fPIC -I/root/repo/venv/include -I/opt/python3.7/include/python3.7m -c _icu.cpp -o build/temp.linux-x86_64-3.7/_icu.o --std=c++0x -I/usr/include -DPYICU_VER="2.4"
    _icu.cpp:54:19: fatal error: tries.h: No such file or directory

I've so far repro'ed this failure on CircleCI doing a gcc x86_64-linux build, and on OS X Mojave using clang.

ovalhub commented 4 years ago

Should be fixed now in PyICU 2.4.1 (two header files were missing from MANIFEST.in).

Andi..

On Mon, 11 Nov 2019, zunger-humu wrote:

pip install is failing on CircleCI (and possibly other platforms -- haven't done a full survey yet) with this:
   x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fstack-protector-strong -g -Wformat -Werror=format-security -fPIC -I/root/repo/venv/include -I/opt/python3.7/include/python3.7m -c _icu.cpp -o build/temp.linux-x86_64-3.7/_icu.o --std=c++0x -I/usr/include -DPYICU_VER="2.4"
   _icu.cpp:54:19: fatal error: tries.h: No such file or directory
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/ovalhub/pyicu/issues/114

zunger-humu commented 4 years ago

Good news: That error no longer happens when trying to compile.

Bad news: Now this one happens instead, same circumstances as before:

    running install
    running build
    running build_py
    creating build
    creating build/lib.linux-x86_64-3.7
    copying PyICU.py -> build/lib.linux-x86_64-3.7
    creating build/lib.linux-x86_64-3.7/icu
    copying icu/__init__.py -> build/lib.linux-x86_64-3.7/icu
    running build_ext
    building '_icu' extension
    creating build/temp.linux-x86_64-3.7
    x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fstack-protector-strong -g -Wformat -Werror=format-security -fPIC -I/root/repo/venv/include -I/opt/python3.7/include/python3.7m -c _icu.cpp -o build/temp.linux-x86_64-3.7/_icu.o --std=c++0x -I/usr/include -DPYICU_VER="2.4.1"
    In file included from _icu.cpp:29:0:
    bases.h:51:12: error: conflicting return type specified for ‘virtual char16_t PythonReplaceable::getCharAt(int32_t) const’
       char16_t getCharAt(int32_t offset) const override;
                ^
    In file included from /usr/include/x86_64-linux-gnu/unicode/unistr.h:30:0,
                     from common.h:106,
                     from _icu.cpp:27:
    /usr/include/x86_64-linux-gnu/unicode/rep.h:231:19: error:   overriding ‘virtual UChar icu_55::Replaceable::getCharAt(int32_t) const’
         virtual UChar getCharAt(int32_t offset) const = 0;
                       ^
    error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

ovalhub commented 4 years ago

Ah, that's different and it seems that in the rather old version of ICU you're building with, ICU 55, that method was declared to return UChar.

https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/classicu_1_1Replaceable.html

I can #ifdef around this but would appreciate some help from you first. Please apply the following patch and try the build again.

------- patch.char16_t

Index: bases.cpp

--- bases.cpp (revision 220) +++ bases.cpp (working copy) @@ -206,7 +206,11 @@ return -1; }

-char16_t PythonReplaceable::getCharAt(int32_t offset) const +#if U_ICU_VERSION_HEX < VERSION_HEX(59, 1, 0)

UChar PythonReplaceable::getCharAt(int32_t offset) const +#else
char16_t PythonReplaceable::getCharAt(int32_t offset) const +#endif { PyObject result = PyObjectCallMethod( self, (char ) "getCharAt", (char *) "i", offset); @@ -223,7 +227,11 @@ if (PyErr_Occurred()) return -1;

+#if U_ICU_VERSION_HEX < VERSION_HEX(59, 1, 0)

return (UChar) n; +#else return (char16_t) n; +#endif }
endif

@@ -235,7 +243,11 @@ if (PyErr_Occurred()) return -1;

+#if U_ICU_VERSION_HEX < VERSION_HEX(59, 1, 0)

return (UChar) n; +#else return (char16_t) n; +#endif }

UnicodeString *u, _u; Index: bases.h

--- bases.h (revision 219) +++ bases.h (working copy) @@ -48,7 +48,11 @@ ~PythonReplaceable();

int32_t getLength() const override; +#if U_ICU_VERSION_HEX < VERSION_HEX(59, 1, 0)
UChar getCharAt(int32_t offset) const override; +#else char16_t getCharAt(int32_t offset) const override; +#endif UChar32 getChar32At(int32_t offset) const override;

void extractBetween(

Thanks !

Andi..

On Mon, 11 Nov 2019, zunger-humu wrote:

Good news: That error no longer happens when trying to compile.

Bad news: Now this one happens instead, same circumstances as before:

   running install
   running build
   running build_py
   creating build
   creating build/lib.linux-x86_64-3.7
   copying PyICU.py -> build/lib.linux-x86_64-3.7
   creating build/lib.linux-x86_64-3.7/icu
   copying icu/__init__.py -> build/lib.linux-x86_64-3.7/icu
   running build_ext
   building '_icu' extension
   creating build/temp.linux-x86_64-3.7
   x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fstack-protector-strong -g -Wformat -Werror=format-security -fPIC -I/root/repo/venv/include -I/opt/python3.7/include/python3.7m -c _icu.cpp -o build/temp.linux-x86_64-3.7/_icu.o --std=c++0x -I/usr/include -DPYICU_VER="2.4.1"
   In file included from _icu.cpp:29:0:
   bases.h:51:12: error: conflicting return type specified for ?virtual char16_t PythonReplaceable::getCharAt(int32_t) const?
      char16_t getCharAt(int32_t offset) const override;
               ^
   In file included from /usr/include/x86_64-linux-gnu/unicode/unistr.h:30:0,
                    from common.h:106,
                    from _icu.cpp:27:
   /usr/include/x86_64-linux-gnu/unicode/rep.h:231:19: error:   overriding ?virtual UChar icu_55::Replaceable::getCharAt(int32_t) const?
        virtual UChar getCharAt(int32_t offset) const = 0;
                      ^
   error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

-- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: https://github.com/ovalhub/pyicu/issues/114#issuecomment-552658159

ovalhub commented 4 years ago

There is a fix in trunk for this. Can you please try it out and let me know if your build completes then ? Thanks !

zunger-humu commented 4 years ago

Sorry this took so long to run -- I just retried it from trunk on CircleCI, and it's now failing with

tries.cpp: In function ‘PyObject* t_ucharstrie_getNextUChars(t_ucharstrie*)’:
tries.cpp:711:32: error: variable ‘icu_55::UnicodeStringAppendable a’ has initializer but incomplete type
     UnicodeStringAppendable a(u);
                                ^

ovalhub commented 4 years ago

Thank you for trying this. It looks like the icu/appendable.h header is not included in common.h where all others are (my bug).

I now checked in a fix in trunk. Please, try it out and let me know if your build completes, or what the next problem is.

Again, thank you for your help and patience. I wish this exercise were easier but I can't possibly test all combinations of ICU versions, compilers, OS, python, etc... I develop on a mac and build on macos and linux, with the latest ICU version (or close), with python 2.7.16 and python 3.8.0)

On Tue, 12 Nov 2019, zunger-humu wrote:

Sorry this took so long to run -- I just retried it from trunk on CircleCI, and it's now failing with
tries.cpp: In function ?PyObject* t_ucharstrie_getNextUChars(t_ucharstrie*)?:
tries.cpp:711:32: error: variable ?icu_55::UnicodeStringAppendable a? has initializer but incomplete type
    UnicodeStringAppendable a(u);
                               ^
-- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: https://github.com/ovalhub/pyicu/issues/114#issuecomment-553132213

zunger-humu commented 4 years ago

It works! Thank you!

ovalhub commented 4 years ago

Excellent, thank you. I'm closing this and releasing 2.4.2.

SethMMorton commented 4 years ago

Again, thank you for your help and patience. I wish this exercise were easier but I can't possibly test all combinations of ICU versions, compilers, OS, python, etc... I develop on a mac and build on macos and linux, with the latest ICU version (or close), with python 2.7.16 and python 3.8.0)

I notice you are using Travis CI. With this, you can test against Linux, macos, and Windows, and test across multiple versions of ICU. If you would like help setting this up, I can try to draft a PR. Doing so will GREATLY reduce stress in making a new release (it did for my python C extension).

ovalhub commented 4 years ago

On Nov 12, 2019, at 19:09, Seth Morton notifications@github.com wrote:

Again, thank you for your help and patience. I wish this exercise were easier but I can't possibly test all combinations of ICU versions, compilers, OS, python, etc... I develop on a mac and build on macos and linux, with the latest ICU version (or close), with python 2.7.16 and python 3.8.0)

I notice you are using Travis CI. With this, you can test against Linux, macos, and Windows, and test across multiple versions of ICU. If you would like help setting this up, I can try to draft a PR. Doing so will GREATLY reduce stress in making a new release (it did for my python C extension).

No, I'm not using it but someone set it up and I know nothing about it. The fact that it's not until I make a release that these errors are surfaced shows that something is not working with this setup.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or unsubscribe.

ovalhub / pyicu

Compilation failure for 2.4 on multiple platforms #114

Index: bases.cpp

endif

UnicodeString *u, _u; Index: bases.h