|
|
|
This thread is locked; no one can reply to it.
|
| No more static link option for libFLAC? |
|
Bruce Pascoe
Member #15,931
April 2015
 |
I downloaded the Allegro 5.1.10 source earlier and went to build it with CMake (I can't use the pre-built MSVC binaries as I static link to the C runtime), and it seems the FLAC_STATIC option is gone, I'm being forced to link to FLAC dynamically now. Kind of a dealbreaker for me as my engine is designed to be self-contained in one .exe file. Is there a way I can force CMake to configure FLAC support anyway so I can static-link manually?
|
|
SiegeLord
Member #7,827
October 2006
 |
This shouldn't be a new change. From what I can tell, the typical way to do it is to do -DFLAC_LIBRARY=your_library. FLAC_STATIC doesn't actually seem to do much, as it doesn't influence which library is found... that probably could be fixed. EDIT: Also, correct me if I'm wrong, but why can't you use the static pre-built libraries? Those shouldn't preclude you from linking in the static runtime, no? "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
Bruce Pascoe
Member #15,931
April 2015
|
Without the FLAC_STATIC option, it finds my static libFLAC.lib, but the FLAC_COMPILES test fails during CMake configuration and it disables support. When linking statically against FLAC, you need to define FLAC__NO_DLL. I assume this is what the FLAC_STATIC option did. As for why I can't use the pre-built binaries: I get link errors like this when using the Multithreaded option for "Runtime Library" in my app, as opposed to Multithreaded DLL: 1>MSVCRT.lib(MSVCR120.dll) : error LNK2005: memmove already defined in LIBCMT.lib(memcpy.obj)
|
|
SiegeLord
Member #7,827
October 2006
|
Oh I see what happened. The compile test for FLAC doesn't respect FLAC_STATIC. I have a fix that I'll commit tomorrow. Interesting news about the other error... I thought it didn't matter how the static libraries were compiled... it's surprising to me that there is some runtime information stored in Allegro's objects... EDIT: The FLAC issue should now be fixed as of http://sourceforge.net/p/alleg/allegro/ci/b0d887b0bcf821cdd4e83da0ee2a09055df02c3d/ "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
Thomas Fjellstrom
Member #476
June 2000
 |
SiegeLord said: it's surprising to me that there is some runtime information stored in Allegro's objects... When you static link libraries to other libraries (ie libc/msvcrt) it will link in the actual functions from it especially ones it can inline. One reason I suggest against static linking complex libraries. You end up with confusing issues down the road when you then try to link your program against the same libs that your libs linked against and then try to use functions they used. You get duplicate symbols. To me it just seems like the libraries are improperly linked. I'm not 100% certain, but I didn't think you actually had to link static libs against their dependencies when building them, a .a/.lib is just supposed to be a ball of unlinked/unresolved object files. -- |
|
Bruce Pascoe
Member #15,931
April 2015
|
What it looks like to me is MSVC links in the C runtime (whatever one you chose), even for a .lib build. There doesn't appear to be a way to stop it from doing it, either. Kind of dumb, but eh. This is why the old unofficial static builds used to have -mt (static runtime) and -md (dynamic runtime) variants, because you can't link either with an executable using the opposite one. Same goes for the debug vs. release runtimes. But the FLAC issue is fixed, thanks!
|
|
SiegeLord
Member #7,827
October 2006
|
I really don't want to have to distribute 4 variants of every binary... what I'll probably do is switch the static binaries to the static runtime, and leave the remaining for the people to build themselves. "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
Bruce Pascoe
Member #15,931
April 2015
|
That makes the most sense, if someone is linking Allegro statically then it's usually because they want to minimize external dependencies (as is the case for me), using the dynamic CRT doesn't really make sense in that case.
|
|
|
