Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failure linking 'analyzer' with global variables [macos] [static] #96

Closed
jgsogo opened this issue Apr 4, 2020 · 6 comments · Fixed by #99
Closed

Failure linking 'analyzer' with global variables [macos] [static] #96

jgsogo opened this issue Apr 4, 2020 · 6 comments · Fixed by #99

Comments

@jgsogo
Copy link
Contributor

jgsogo commented Apr 4, 2020

Hi! I'm trying to compile the project from sources (release 4.1) in Macos (10.15.3) and I'm getting a link error in the analyzer and the threaded_analyzer (same linking error) when using static linking:

[ 93%] Linking CXX executable ../../../bin/threaded_analyzer
Undefined symbols for architecture x86_64:
  "_g_defines", referenced from:
      _fsm_parse_regex_string in libfoma.a(lex.yy.c.o)
      _yylex in libfoma.a(lex.yy.c.o)
  "_g_defines_f", referenced from:
      _fsm_parse_regex_string in libfoma.a(lex.yy.c.o)
      _yylex in libfoma.a(lex.yy.c.o)
ld: symbol(s) not found for architecture x86_64

Is it intended? Can I compile Freeling statically?

Thanks!

@lluisp
Copy link
Contributor

lluisp commented May 18, 2020

Static linking is not supported. FreeLing is a large library that uses a lot of other libraries.
A static binary would be huge, and I am not sure it makes much sense.

However, if you want to do that, the errors seems to indicate that you are missing some library.
You should find out which library provides "_g_defines", get a static version of it, and maybe add it to cmake files.

@jgsogo
Copy link
Contributor Author

jgsogo commented May 18, 2020

I'll have a look at it. Static linking is preferred by a lot of people in the C++ community, it allows for some optimization (LTO) and I think that another reason is that it avoids DLL-hell and dependency management problems.

Static binary shouldn't be that big, these are the numbers I get from #97 where I've just added the fix for this issue: g_defines is declared in foma library but defined in the main() function of foma.c which have been removed in the copy inside this repository. Static linking detects this issue while dynamic would fail in runtime if used.

I can isolate needed changes, but I would prefer to have a CI working so I can know that my changes are not breaking anything else.


Dynamic linking

⇒  ls -la install/bin 
total 4960
drwxr-xr-x  10 jgsogo  staff      320 18 may 22:16 .
drwxr-xr-x   6 jgsogo  staff      192 18 may 21:04 ..
-rwxr-xr-x   1 jgsogo  staff     1028  4 abr 19:49 analyze
-rwxr-xr-x   1 jgsogo  staff   300880 18 may 22:16 analyzer
-rwxr-xr-x   1 jgsogo  staff    49344 18 may 22:16 analyzer_client
-rwxr-xr-x   1 jgsogo  staff    85476 18 may 22:16 convert_model
-rwxr-xr-x   1 jgsogo  staff    37284 18 may 22:16 crfsuite
-rwxr-xr-x   1 jgsogo  staff      999  4 abr 19:49 fl_initialize
-rwxr-xr-x   1 jgsogo  staff   335368 18 may 22:16 threaded_analyzer
-rwxr-xr-x   1 jgsogo  staff  1708792 18 may 22:16 treeler
⇒  ls -la install/lib 
total 26448
drwxr-xr-x  7 jgsogo  staff      224 18 may 22:16 .
drwxr-xr-x  6 jgsogo  staff      192 18 may 21:04 ..
-rwxr-xr-x  1 jgsogo  staff   165972 18 may 22:16 libcrfsuite.dylib
-rwxr-xr-x  1 jgsogo  staff  8853324 18 may 22:16 libdynet.dylib
-rwxr-xr-x  1 jgsogo  staff   304724 18 may 22:16 libfoma.dylib
-rwxr-xr-x  1 jgsogo  staff  3898584 18 may 22:16 libfreeling.dylib
-rwxr-xr-x  1 jgsogo  staff   309740 18 may 22:16 libtreeler.dylib

plus boost, icu, zlib, eigen and bzip2

Static linking

⇒  ls -la ./install/bin 
total 43440
drwxr-xr-x  10 jgsogo  staff       320 18 may 22:20 .
drwxr-xr-x   6 jgsogo  staff       192 18 may 21:36 ..
-rwxr-xr-x   1 jgsogo  staff      1028  4 abr 19:49 analyze
-rwxr-xr-x   1 jgsogo  staff  13898276 18 may 22:20 analyzer
-rwxr-xr-x   1 jgsogo  staff     49344 18 may 22:20 analyzer_client
-rwxr-xr-x   1 jgsogo  staff   1749752 18 may 22:20 convert_model
-rwxr-xr-x   1 jgsogo  staff     37284 18 may 22:20 crfsuite
-rwxr-xr-x   1 jgsogo  staff       999  4 abr 19:49 fl_initialize
-rwxr-xr-x   1 jgsogo  staff   4632912 18 may 22:20 threaded_analyzer
-rwxr-xr-x   1 jgsogo  staff   1844120 18 may 22:20 treeler

jgsogo added a commit to jgsogo/FreeLing that referenced this issue May 18, 2020
@lluisp
Copy link
Contributor

lluisp commented May 19, 2020 via email

@jgsogo
Copy link
Contributor Author

jgsogo commented May 19, 2020

Hi! I totally understand your concerns and I would think exactly the same if I hadn't used Travis/Appveyor/Github-actions/CircleCI/Azure/... before but in my experience it is the other way around: having those systems enabled helps the maintainers to know that everything keeps working without having to check it with every change. Files for those systems also contain the instructions for developers to compile the library (this is what I have a look to when I need to build a library).

I will submit small changes to improve the build system step by step, that's not a problem (and it is the reason why the big PR is a draft, not to be merged but to talk about it). So, let's go step by step. I'll keep Travis running in my fork (I'll add Appveyor for Windows as soon as I managed to compile it) so we can help some colleagues out there.

Thanks for all your efforts!

@lluisp
Copy link
Contributor

lluisp commented May 19, 2020 via email

@jgsogo
Copy link
Contributor Author

jgsogo commented May 19, 2020

Yes, those are instructions for developers. Users should have binary packages available out-of-the-box. Any CI should compile the library (instruction for developers) and upload generated binaries (for different distros, windows versions,.... whatever is needed) somewhere so users can download them (FTP, Unix ppa, snap, flatpack, bintray, webpage,...).

What are your ideas for "not depending on MSVC for windows"? What compiler do you want to use?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants