luni can't be built with clang

[PerfectCarl]

The file java_text_Bidi.cpp can't be built with clang because of a MACRO error in icu4c.

The complete error is:

\android\libcore\luni\src\main\native\java_text_Bidi.cpp:9
2:5: error:
      no matching function for call to 'ubidi_setPara_51'
    ubidi_setPara(data->uBiDi(), chars.get(), length, paraLevel, data->embeddingLevels(), &err);
    ^~~~~~~~~~~~~
\android\libcore\luni\src\main\native\..\..\..\..\..\exter
nal\icu4c\common\unicode/urename.h:466:23: note:
      expanded from macro 'ubidi_setPara'
#define ubidi_setPara U_ICU_ENTRY_POINT_RENAME(ubidi_setPara)
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\android\libcore\luni\src\main\native\..\..\..\..\..\exter
nal\icu4c\common\unicode/uvernum.h:114:40: note:
      expanded from macro 'U_ICU_ENTRY_POINT_RENAME'
#define U_ICU_ENTRY_POINT_RENAME(x)    U_DEF2_ICU_ENTRY_POINT_RENAME(x,U_ICU_VERSION_SUFFIX)
                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\android\libcore\luni\src\main\native\..\..\..\..\..\exter
nal\icu4c\common\unicode/uvernum.h:113:44: note:
      expanded from macro 'U_DEF2_ICU_ENTRY_POINT_RENAME'
#define U_DEF2_ICU_ENTRY_POINT_RENAME(x,y) U_DEF_ICU_ENTRY_POINT_RENAME(x,y)
                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\android\libcore\luni\src\main\native\..\..\..\..\..\exter
nal\icu4c\common\unicode/uvernum.h:112:43: note:
      expanded from macro 'U_DEF_ICU_ENTRY_POINT_RENAME'
#define U_DEF_ICU_ENTRY_POINT_RENAME(x,y) x ## y
                                          ^~~~~~
<scratch space>:196:1: note: expanded from here
ubidi_setPara_51
^~~~~~~~~~~~~~~~
\android\libcore\luni\src\main\native\..\..\..\..\..\exter
nal\icu4c\common\unicode/ubidi.h:1217:1: note:
      candidate function not viable: no known conversion from 'const jchar *' (aka 'const unsigned short *') to
      'const UChar *' (aka 'const wchar_t *') for 2nd argument
ubidi_setPara(UBiDi *pBiDi, const UChar *text, int32_t length,
^
\android\libcore\luni\src\main\native\..\..\..\..\..\exter
nal\icu4c\common\unicode/urename.h:466:23: note:
      expanded from macro 'ubidi_setPara'
#define ubidi_setPara U_ICU_ENTRY_POINT_RENAME(ubidi_setPara)
                      ^
\android\libcore\luni\src\main\native\..\..\..\..\..\exter
nal\icu4c\common\unicode/uvernum.h:114:40: note:
      expanded from macro 'U_ICU_ENTRY_POINT_RENAME'
#define U_ICU_ENTRY_POINT_RENAME(x)    U_DEF2_ICU_ENTRY_POINT_RENAME(x,U_ICU_VERSION_SUFFIX)
                                       ^
\android\libcore\luni\src\main\native\..\..\..\..\..\exter
nal\icu4c\common\unicode/uvernum.h:113:44: note:
      expanded from macro 'U_DEF2_ICU_ENTRY_POINT_RENAME'
#define U_DEF2_ICU_ENTRY_POINT_RENAME(x,y) U_DEF_ICU_ENTRY_POINT_RENAME(x,y)
                                           ^
\android\libcore\luni\src\main\native\..\..\..\..\..\exter
nal\icu4c\common\unicode/uvernum.h:112:43: note:
      expanded from macro 'U_DEF_ICU_ENTRY_POINT_RENAME'
#define U_DEF_ICU_ENTRY_POINT_RENAME(x,y) x ## y
                                          ^
<scratch space>:165:1: note: expanded from here
ubidi_setPara_51
^

Note : the file is built correctly with gcc. Note: icu4c is successfully built with clang.

[dicej]

FYI, I probably won't have time in the foreseeable future to debug this or the other issues you entered recently. You might want to ping @bigfatbrowncat and @JustAMan about them.

Going forward, I'd like to see someone else take ownership of this project, i.e. move it elsewhere in Github so it's no longer "my" project. I don't have much personal or professional time/interest in it besides making sure Avian continues to be compatible, so I'd prefer to let someone who really cares about it take charge.

[bigfatbrowncat]

Hi, Joel! Although it's not the topic here, I want to ask you if you would spend a little more time and help us (@bigfatbrowncat and @JustAMan) to negotiate with Google about merging the current version upstream? It's sufficiently stable on Windows (and I strongly hope that it's not broken on any other platform). Besides, we should beat a path for possible future commits...

I think that supporting the whole libcore is too tough burden for a couple of enthusiasts...

To @PerfectCarl : unfortunately we don't use clang on any system besides OS X (where it's not an option). On Windows we use MinGW-w64 GCC toolchain.

[PerfectCarl]

@bigfatbrowncat That's understandable.

As I am in the process of building libcore/luni 32bits on my windows 7 box, I thought it was always interesting to keep track of the issues. For the sake of completion.

Your fork not supporting issues, I revert to this repository. Which may or may not the proper thing to do as @dicej pointed out.

Note: clang version: 3.3.0 (maybe I shall try with 3.4...)

[dicej]

@bigfatbrowncat, feel free to raise the issue of merging the Windows port upstream on https://groups.google.com/forum/#!forum/android-contrib, but I don't think they will unless Google has a business reason to do it, which they apparently don't. I don't think we have any leverage to negotiate -- it would cost them time and effort (e.g. regression testing, making sure new commits don't break the Windows port, etc.) to merge these changes without much benefit to the company. I don't want to maintain it either, so I understand their position :)

If you feel like maintaining a fork is too much effort for 2-3 people, you might need to look elsewhere besides Google for help.

[dicej]

@PerfectCarl, I guess GitHub doesn't let you create issues for forks. You're welcome to open issues on this repo, and I'll certainly accept pull requests, but I don't plan to work on the issues myself.

[PerfectCarl]

@dicej The issue management (and wiki) is a setting that you must enable after a fork. In the settings.

but I don't plan to work on the issues myself.

Duly noted. When (or if) I get somewhere I'll submit patches :)

[bigfatbrowncat]

Ok, I'll enable it now

Done. You can add issues into my repo now. Thank you for any help.