#232 Latest Win32 binaries are incomplete

[Casey Langen]

Hi there!

I'm using mpg123 for decoding mpeg files in my project. In the process of updating dependencies I found that the latest win32 (and also win64) builds -- 1.23.4 at the time of this writing -- are missing a couple very important files.

Specifically, libmpg123.dll.a (and the other .a) files are not present, so we cannot link against the DLLs easily using standard MSVC build tools. These files are present in older versions of the distribution, so I'm currently using 1.23.0 instead of 1.23.4. Note that supplying a module definition file (.def) would also be fine, because we can use that to generate the missing library per http://stackoverflow.com/a/15226566.

I think the absense of these files is a small oversight... is there any chance us poor Windows users can get an updated package with the missing files? :)

Thanks!
Casey

PS: "ssize_t" was also undefined in the (1.23.0) distribution, so I had to typedef it manually.

[Jonathan Yong]

The build scripts is only recently fixed in SVN. Thomas, do you mind making a new release 1.23.5 release?

[Thomas Orgis]

Am Sun, 29 May 2016 23:12:47 +0000
schrieb "Jonathan Yong":

The build scripts is only recently fixed in SVN. Thomas, do you mind
making a new release 1.23.5 release?

Yeah, sure, I was about to do that. But I wonder about this one:

PS: "ssize_t" was also undefined in the (1.23.0) distribution, so I
had to typedef it manually.

What are we missing there?

[Casey Langen]

My project just does an "#include <mpg123.h>", which seems to work fine in Linux and OSX. On Windows/MSVC the compiler complains that "ssize_t" is undefined. It's easily fixed by doing a "typedef long ssize_t;" before the #include, but certainly isn't ideal.

Thanks for quick response to my original post.

[Thomas Orgis]

Am Mon, 30 May 2016 06:54:12 +0000
schrieb "Casey Langen":

My project just does an "#include <mpg123.h>", which seems to work
fine in Linux and OSX. On Windows/MSVC the compiler complains that
"ssize_t" is undefined. It's easily fixed by doing a "typedef long
ssize_t;" before the #include, but certainly isn't ideal.

So you are not using ports/MSVC++/mpg123.h, which contains that
typedef, too … we do have those MSVC projects there, but they tend to
need some manual care as we do not regularily test them.

[Casey Langen]

Yeah, originally tried to compile from source, but it didn't build out of the box with MSVC2015. After fiddling with it for a while I decided to just use binaries -- I'd rather not go through that process every time I need to upgrade.

As you know, the binary distribution contains the header files, which is what I used above. Ideally they'd "just work".

[Thomas Orgis]

Am Mon, 30 May 2016 19:14:44 +0000
schrieb "Casey Langen":

MSVC2015

As you know, the binary distribution contains the header files, which
is what I used above. Ideally they'd "just work".

We define ssize_t in the special header used inside MSVC for building
mpg123. I wonder how we properly should support linking with either
MSVC or mingw. What header should be shipped?

Jon: Should there be MSVC detection in the normal header and then
ssize_t defined … and to what should it be defined? I see

https://sourceforge.net/p/mpg123/bugs/183/

So … I agree that linking to the libmpg123 binaries should be possible
with MSVC. And What's about the

#define MPG123_EXPORT __declspec(dllimport)

thing? Isn't it needed? The mpg123 build itself does this.

#if defined(WIN32) && defined(DYNAMIC_BUILD)
#define LINK_MPG123_DLL
#endif

So, I guess things should be workable if we amend the mpg123.h in the
binary distribution. What about the other settings in
ports/MSVC++/mpg123.h? Like, mpg123_topen() … ?

--
Thomas Orgis - Source Mage GNU/Linux Developer (http://www.sourcemage.org)
OrgisNetzOrganisation ---)=- http://orgis.org
GPG public key 60D5CAFE: http://thomas.orgis.org/public_key
Fingerprint: D021 FF8E CF4B E097 19D6 1A27 231C 4CBC 60D5 CAFE

[Jonathan Yong]

I think we should be fine doing MSVC magic in the headers, eg:

if msvc > version_old

if msvc > version_newer

...

endif

endif

So in case MSVC ever supports ssize_t, we can work around that.
Casey, do you know the macro to check for? (I don't have MSVC installed)

[Casey Langen]

I think _MSC_VER is what you're looking for: http://stackoverflow.com/a/70630. For what it's worth, I'm using VS 2015.

[Thomas Orgis]

Am Wed, 01 Jun 2016 00:54:35 +0000
schrieb "Casey Langen":

I think _MSC_VER is what you're looking for: http://stackoverflow.com/a/70630. For what it's worth, I'm using VS 2015.

Well, we got that in the header for building libmpg123 itself … see
ports/MSVC++/mpg123.h . Also, what about the _TCHAR stuff in
ports/MSVC++/msvc.c? I'm not sure how that relates to our win32 unicode
support.

--
Thomas Orgis - Source Mage GNU/Linux Developer (http://www.sourcemage.org)
OrgisNetzOrganisation ---)=- http://orgis.org
GPG public key 60D5CAFE: http://thomas.orgis.org/public_key
Fingerprint: D021 FF8E CF4B E097 19D6 1A27 231C 4CBC 60D5 CAFE

[Casey Langen]

Ah, right. But none of those definitions are present in the header files distributed with the binaries, which are compatible with MSVC (assuming the .a or .def files are also distributed). Is it unesireable to include these missing definitions in the mpg123.h that's included in the win32 tarball?

The TCHAR stuff seems to just be a small convience layer that supports loading files using both 8- and 16-bit character strings -- just standard Win32 grossness.

[Thomas Orgis]

Jonathan, I'd like to have the distributed headers amended so that they work with MSVC.

Can we settle on the right macros to guard that ssize_t definition with? Anything else we have to include (I figure that TCHAR stuff is not essential)?

[Jonathan Yong]

Give this a try, it is a 64bit build. Extract over an existing version and replace the files.

[Casey Langen]

Hey Jonathan,

My project is currently 32-bit on Windows, would it be possible for you to supply a 32-bit build? However, just to test, I used the header files from your zip file above (1.23.5), and was able to compile (then link against the old binaries) without the ssize_t typedef in my code!

Thanks!
Casey