PerfectLib compiled, but PerfectServer failed about perfect HOT 7 CLOSED

Try the following and let me know what you see:
sudo updatedb
locate libicui18n.so

And give this a try:
sudo apt-get install libicu-dev

So far we have only built on 15.10. I'll start a 14.04 install now.

from perfect.

Thanks for the prompt reply!

libicu-dev was already installed. Output of locate:

$ locate libicui18n.so
/usr/lib/x86_64-linux-gnu/libicui18n.so
/usr/lib/x86_64-linux-gnu/libicui18n.so.52
/usr/lib/x86_64-linux-gnu/libicui18n.so.52.1

from perfect.

Ok, I see. Unfortunately, ICU appends the version number onto each function name. The ICU which gets installed on 15.10 is 5.5, thus the _55 at the end of the undefined functions.

I'll have to consider how to better handle this without forcing people to have to build ICU themselves as a dependency.

from perfect.

No worries, I can spin up a 15.10 instance. Its all good - thanks for jumping on this so quickly.

from perfect.

I looked into this issue as I'm also hitting it on 14.04. It seems that Ubuntu is one of the only platforms where the libicu package is built with symbol renaming enabled, and the maintainer's reasoning behind this decision is discussed here: http://sourceforge.net/p/icu/mailman/icu-design/thread/[email protected]/

I believe that the best solution for this issue is to include libicu sources and build a libicu.a as part of the build process for PerfectLib (and is linked into PerfectLib.so). I agree that it would be nice to avoid this. However, it seems that would cause more hassle than it's worth. Plus, relying on the system's libicu will likely cause instability seeing as the developers are so uncertain of the ABI compatibility that they added this crazy per-version symbol renaming "feature".

from perfect.

Continued looking into the issue, and here's what I found. The renaming in libicu comes from urename.h. Every symbol is #defineed to include the version suffix, for example it defines udat_open to be udat_open_55 for libicu with major version 55. Therefore, C code using libicu is not subject to these naming issues, as you can and should just use the raw defines without the version suffix in C. This only works if we use the system's ICU headers, however, as they will have the macros providing the correct version suffix. This leads me to believe that the best approach is to provide a C function wrapper for any renamed libicu methods that should be used from Swift code (for example, udat_open_wrapper), and to rely on the system's libicu headers.

I did a bit of searching, and there aren't too many references to these renamed symbols in PerfectLib. Here's a summary of the references I found to renamed symbols in libicu from Swift code:

• SessionManager.swift
  • Imported function ICU.ucal_getNow_55, but never used (looks like the code was later changed to instead use ICU.getNow())
• ICU.swift
  • u_isWhitespace_55
  • u_isdigit_55
  • u_isalnum_55
  • ucal_getNow_55
  • u_errorName_55
  • udat_open_55 another
  • udat_close_55 another
  • udat_parse_55
  • udat_format_55

So these listed functions need to be wrapped, and the system's headers need to be used instead of providing headers from a specific version.

I can continue working on this issue and submit a pull request if you'd like.

from perfect.

Oh, OS X doesn't provide headers for its /usr/lib/libicucore.dylib (which does have all the functions we need). How fun.

from perfect.