Static versus dynamic linking

[GoogleCodeExporter]

When I made a public release candidate Windows binary, I came to find that 
libvorbis-3.dll hadn't been statically linked by MinGW.  Maybe the 3.4.5 
versions of MinGW don't do this for various libraries (including libgcc).  
Theoretically, the "--disable-shared" switch will ensure that all libraries get 
statically linked, but allowing them to be dynamically linked brings the 
overall executable size down (ie. this release candidate is considerably 
smaller than 1.666, even with the new OGG files and features).  We should 
consider whether or not to continue using the dynamic linking feature.  So far, 
I've only had to add the one DLL file for people to be able to run the binary, 
and it's only a measly 54KB.

Original issue reported on code.google.com by raynebc on 4 Oct 2010 at 2:29

[GoogleCodeExporter]

It was suggested in the Allegro IRC channel that when I built Libvorbis, it was 
built dynamically instead of statically.  This would either be due to the 
makefile given with the vorbis source or the behavior of the version of MinGW 
that I have.

That 1.7RC1 is more than a half megabyte smaller than 1.666 is either due to 
the linking behavior, my code optimizations or both.

Original comment by raynebc on 4 Oct 2010 at 2:37

[GoogleCodeExporter]

Various vorbis libraries aren't linking into the executable, causing problems.  
I'm currently trying to rebuild the libraries as static instead of shared, but 
so far I'm not able to build EOF after doing so.

Original comment by raynebc on 4 Oct 2010 at 11:32

• Changed state: Started

[GoogleCodeExporter]

In total, the following 3 DLLs had to be packaged with the release candidate:
libogg-0.dll
libvorbis-0.dll
libvorbisfile-3.dll

Original comment by raynebc on 5 Oct 2010 at 6:20

[GoogleCodeExporter]

This has nothing to do with EOF's code, so I'll close the issue.

Original comment by raynebc on 9 Jan 2011 at 11:00

• Changed state: WontFix