icu icon indicating copy to clipboard operation
icu copied to clipboard

ICU-21627 - Fix Makefile bugs

Open pchemguy opened this issue 3 years ago • 4 comments

The two libraries are in the wrong order causing the static build to fail (at least on Windows). There are three more Makefile's (in tests and samples) with the same issue. However, those have no apparent effect on the build process (it completes successfully), so I did not fix them.

Static libraries should not use numeric suffixes on the MinGW/Windows platform. Additionally, the static "s" suffix should also be dropped.

https://unicode-org.atlassian.net/browse/ICU-21627

Checklist
  • [x] Required: Issue filed: https://unicode-org.atlassian.net/browse/ICU-21627
  • [x] Required: The PR title must be prefixed with a JIRA Issue number.
  • [x] Required: The PR description must include the link to the Jira Issue, for example by completing the URL in the first checklist item
  • [x] Required: Each commit message must be prefixed with a JIRA Issue number.
  • [ ] Issue accepted (done by Technical Committee after discussion)
  • [ ] Tests included, if applicable
  • [ ] API docs and/or User Guide docs changed or added, if applicable

pchemguy avatar May 27 '21 17:05 pchemguy

Thanks for this PR! I've tried cross-compiling from Linux to MinGW, and the resulting data lib has the wrong name (icudt.a instead of libicudt.a) and is in the wrong directory (bin instead of lib). Can you look into why this is the case?

longnguyen2004 avatar Jun 06 '21 06:06 longnguyen2004

This is strange. I just compiled again (Windows/MSYS2?MinGW) a few times, and I noticed that I also have issues with *icudt.*: In the build/lib I get "liblibicudt.dll.a" and "libliblibicudt.a", that is with 2x and 3x "lib". In the dist/bin, I also have *icudt.a (the rest are in the dist/bin, but the file is named "libliblibicudt.a" (3x "lib"), not "icudt.a". The problem is, I am not very experienced with makefiles, and the ICU build system with all these recursive calls and multiple makefiles spread across various dirs with very few comments, it is really hard for me to pinpoint the lines where the relevant name of a given target is actually formed.

I made a mistake. Everything above is valid for the v68 branch. I just rerun the build process for the main branch. I get a similar result, except, curiously the names are now "libicudt.dll.a" and "liblibicudt.a", that is the first one has one "lib", which is correct, and the second has 2x instead of 3x "lib".

pchemguy avatar Jun 08 '21 14:06 pchemguy

You can try to run pkgdata with --verbose to see debug info about the library name, MinGW is a bit of a mess right now. Also, pkgdata also need some rework to properly accommodate cross compilation. I've already created an issue for that.

longnguyen2004 avatar Jun 08 '21 16:06 longnguyen2004

I also encountered similar problem when trying to build icu4c in Windows 10's msys2 + MinGW64 environment. These are steps that we can use to reproduce failures:

# Start MSYS2 MinGW64 Terminal Window with built-in MinGW64 environment
pacman -Syu
pacman -Sy base-devel mingw-w64-x86_64-toolchain
pacman -Sy git mingw-w64-x86_64-cmake mingw-w64-x86_64-ninja
git clone https://github.com/unicode-org/icu.git
cd icu/icu4c/source
./runConfigureICU MinGW --enable-static --disable-shared
make -j4

And we can get some undefined references not found failures. But if we remove --disable-shared from runConfigureICU, it can pass the building.

utzcoz avatar Feb 19 '23 13:02 utzcoz