-
Notifications
You must be signed in to change notification settings - Fork 99
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
Comments
Static linking is not supported. FreeLing is a large library that uses a lot of other libraries. However, if you want to do that, the errors seems to indicate that you are missing some library. |
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: 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
plus Static linking
|
I am really reluctant to make such big changes to the building procedure.
FreeLing is a low-resource project, and we don't have the manpower to
change and maintain all this.
I don't like either the idea of depending on yet another external
platform like travis or the like.
Moreover, the update rate is also pretty slow, so continuous integration
is not a must.
In any case, I am willing to make the changes needed to allow static
linking.
It seems that foma.h will define those symbols when compiled with
-DMAIN_MODULE, so that may be the easiest way.
FreeLing uses limited functions from foma, and that is not causing any
problems with dynamic linking, meaning they are not used.
best
Lluis
…On 18/5/20 22:25, Javier G. Sogo wrote:
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 <#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 |
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#96 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANH565XLFGJAE4PDQ6F7CDRSGKTBANCNFSM4L6YK6CQ>.
|
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! |
I understand, but you are a developer, so you are able to read those
instructions, or use cmake, install a compiler...
The people you are trying to help probably struggle just with installing
a compiler. They need out-of-the box binary packages.
I'd prefer to improve the building system in the line of keeping cmake
and easing the build of binary packages.
Some things that would be great:
1) not depending on MSVC for windows.
2) including working java and python APIs in the binary packages
…On 19/5/20 11:16, Javier G. Sogo wrote:
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 <https://twitter.com/JMFradeRue/status/1255747683974885376>.
Thanks for all your efforts!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#96 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANH564BSZJNUZ2TJCLYPN3RSJE7NANCNFSM4L6YK6CQ>.
|
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? |
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 thethreaded_analyzer
(same linking error) when using static linking:Is it intended? Can I compile Freeling statically?
Thanks!
The text was updated successfully, but these errors were encountered: