mpg123 / Bugs / #374 "unresolved external symbol mpg123

Martin - 2024-11-21

https://sourceforge.net/p/mpg123/bugs/310/ seems possibly relevant as it is missing the same export there... can I not edit my tickets on SF? :/

This is on a W11 VM, C++2022 tooling from MS.

Looks like if MPG123_PORTABLE_API is defined it won't have _open? But shouldn't it have _open_64 in that case at least?
https://mpg123.org/api/mpg123_8h_source.shtml

Will try and see if that is somehow there...

EDIT: So MPG123_PORTABLE_API was added in 1.31.
I downgraded vcpkg.json to 1.29.3.
I removed the fpu patch in portfile.cmake and replaced hash with SHA512 0d8db63f9bae1507887bc5241a56abccfeb767b7ba8362eb0fce9de2f63369e57fdd6f25a953f8ef5f9ead4f400237db51914816e278566fdf8e6f205ebca5d6.
Removed and installed mpg123 again and now the symbols are there.

Last edit: Martin 2024-11-21

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Thomas Orgis - 2024-11-22

Where is MPG123_PORTABLE_API defined? I don't see it in

https://github.com/microsoft/vcpkg/blob/master/ports/mpg123/portfile.cmake

Yes, with portable API, you don't have mpg123_open varants at all. No file I/O.

If you want that, you should push for upgrading to 1.23.9 in vcpgk, anyway, as that enables 64 bit offsets with MSVC.

And what about hat FPU patch? Always force FPU on when cross compiling? Doesn't sound right.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Martin - 2024-11-22

And what about hat FPU patch? Always force FPU on when cross compiling? Doesn't sound right.

It conflicts on the older version, so I just removed it.

Where is MPG123_PORTABLE_API defined? I don't see it in

No idea, couldn't find it either, might not even be the issue, but the older version works for some reason.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Thomas Orgis - 2024-11-22
  
  And what about trying the current version? It has build changes vor msvc...
  
  Am 22. November 2024 12:30:09 MEZ schrieb Martin c0rn3j@users.sourceforge.net:
  
  And what about hat FPU patch? Always force FPU on when cross compiling? Doesn't sound right.
  
  It conflicts on the older version, so I just removed it.
  
  Where is MPG123_PORTABLE_API defined? I don't see it in
  
  No idea, couldn't find it either, might not even be the issue, but the older version works for some reason.
  
  [bugs:#374] "unresolved external symbol mpg123_open" when installing from vcpkg
  
  Status: open
  Release Series: 1.32.x
  Created: Thu Nov 21, 2024 05:07 PM UTC by Martin
  Last Updated: Fri Nov 22, 2024 06:23 AM UTC
  Owner: nobody
  
  I will admit I am completely green in trying to get anything C/C++ done on Windows, so this may be an issue between a chair and the keyboard.
  
  I grabbed vcpkg.exe from https://github.com/microsoft/vcpkg-tool/releases/tag/2024-11-12, cloned the repo, put it in it, and ran ./vcpkg.exe install mpg123:x64-windows, among other dependencies I needed to attempt to build my devel branch of Tauon on native Windows - https://github.com/C0rn3j/Tauon/tree/newdevel
  
  However, when the build system gets to building Phazor trying to run python -m build --wheel, I get an error:
  phazor.obj : error LNK2001: unresolved external symbol mpg123_open
  
  LLM suggested to verify the symbols are exported via dumpbin, so I tried, and indeed it does not seem to be there:
  
  &"C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.42.34433\bin\Hostx64\x64\dumpbin.exe" /EXPORTS C:\Users\Yeet\Tauon\vcpkg\installed\x64-windows\lib\mpg123.lib ... mpg123_new_string mpg123_open_feed mpg123_open_handle mpg123_outblock mpg123_par ...
  
  Checking the vcpkg status file shows it installed a package 2 minor versions behind, but it seems to mostly be a security issue fix, so I take it it's not relevant:
  
  yaml Package: mpg123 Version: 1.32.7 Depends: vcpkg-cmake, vcpkg-cmake-config, yasm Architecture: x64-windows Multi-Arch: same Abi: c4ae25a88fe669cbc8a7a4efb9691bfe1b95d6b4e6f8ce275bb04bcaae8c39ea Description: mpg123 is a real time MPEG 1.0/2.0/2.5 audio player/decoder for layers 1, 2 and 3 (MPEG 1.0 layer 3 also known as MP3). Status: install ok installed
  
  What am I doing wrong here?
  
  Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/mpg123/bugs/374/
  
  To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
  
  --
  sent from mobile device, trustworthy or not
  
  Related
  
  Bugs: ~~#374~~
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Martin - 2024-11-22
    
    Bumping to 1.32.9 and changing hash to dccb640b0845061811cb41bf145587e7093556d686d49a748232b079659b46284b6cc40db42d14febceac11277c58edf2b69d1b4c46c223829a3d15478e2e26c and resetting the rest to stock repo results in the same exact situation with missing symbols.
    
    Here is the full debug build log + dumpbin:
    https://paste.rys.rs/?9cb4e787f5363143#BkWCHptnGA1H8pDY2a6u1pdNUHnUUWRbvtvMFowGE24a
    
    EDIT: Reported downstream as https://github.com/microsoft/vcpkg/issues/42319 and https://github.com/microsoft/vcpkg/issues/42318
    
    Last edit: Martin 2024-11-22
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Thomas Orgis - 2024-11-22

You're not just running a PORTABLE_API build. Using that gives you 116 symbols lin libmpg123 (with autoconf and cmake on Linux, though the cmake build is buggy in that it also exports the INT123_ symbols). You got 130. This is something in between.

Edit: Nope. Suffixes should not matter for MSVC! I wonder how the business with MPG123_EXPORT works out, which seems to conflict with the idea of providing functions with and without _64 suffix, or _32 suffix, for that matter. All in all, we recently added real 64 bit offset support to the MSVC builds … it makes sense to have suffix-less symbols there, as there is no largefile switch.

So, ideally, you should have the normal set of functions and also those with the plain 64 suffix (no underscore), which is the safe 64 bit API. You might consider switching your application to those.

But this doesn't explain internal I/O being gone … or does it? We tried to fix it, even adding the MPG123_COMPAT_MSVCRT_IO stuff in compat. Can you check the objects if the missing symbols are built and just missing in the library exports? Does the sledgehammer of CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS work? (gleaned from https://stackoverflow.com/questions/64088046/missing-lib-file-when-creating-shared-library-with-cmake-and-visual-studio-2019)

Or … perhaps our export symbol handling it total crap. https://discourse.cmake.org/t/correct-import-export-of-symbols-from-library/7858/2 … maybe we need to generate a separate export header that explicitly states all symbols. But thinking again … now, the business with _32 or _64 aliases should not bother you on MSVC, as you should not build with -DFILE_OFFSET_BITS=xx. Vcpkg doesn't do that, right?

I'm wondering right now how I can make cmake not export all symbols on Linux: There, it's too many (not only those prefixed with mpg123_). For you, it's not enough. My suspicion is that it's just a visibility thing.

I hope vcpkg folks can quickly resolve this. I cannot make much of your build logs. First thing would be to find out if there is a non-exported symbol for mpg123_open in there.

Last edit: Thomas Orgis 2024-11-22

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Thomas Orgis - 2024-12-09

Copying my reply to the vcpkg issue:

Yes … the MPG123_EXPORT switchery. I need to recap that myself. Right from the top: How important is __declspec(dllimport) for a client build, anyway? The mpg123 headers define MPG123_BUILD_DLL and MPG123_LINK_DLL accordingly for library and client code (common/abi_align.h, src/mpg123app.h and individual sources).

Does the client code that misses the symbols actually define MPG123_LINK_DLL to get the dllimport? I guess we should put a platform check into mpg123.h to default to a client build on Windows? But apparently it works without? I'm working only on hearsay regarding Microsoft platforms.

Apart from that question, I see how it went wrong with libmpg123.c. It does need the header definitoons for the functions that are not to be used internally, but defined. This change should help:

Index: src/libmpg123/mpg123lib_intern.h =================================================================== --- src/libmpg123/mpg123lib_intern.h (revisión: 5447) +++ src/libmpg123/mpg123lib_intern.h (copia de trabajo) @@ -21,7 +21,10 @@ // Only portable API plays a role in the library itself, outside of lfs_wrap.c. // Also, we need to ensure no suffix renaming for the primary implementations. -#define MPG123_PORTABLE_API +// But: The _definition_ of non-portable API needs to be present for those +// primary implementations being exported for DLL builds. Just the largefile +// renaming needs to be skipped! +#define MPG123_NO_LARGENAME #define MPG123_ENUM_API #include "mpg123.h"

Once I get a confirmatiion from an vcpkg MSVC build, I'll ship the fix. But also, I'd like to have something in place to make the header work for clients without defining MPG123_LINK_DLL. I guess such requirement is unusual. Should I just do this?

#if (defined(_WIN32) && !defined(MPG123_BUILD_DLL) && !defined(MPG123_LINK_DLL) #define MPG123_LINK_DLL #endif

I added the indicated change to mpg123 repo and am building a new https://mpg123.org/snapshot now (ready in a minute). Can you try this?

Edit: I did not add the MPG123_LINK_DLL part. So far it was not missed, but it looks like you'd want it. Input welcome.

Last edit: Thomas Orgis 2024-12-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- manx - 2024-12-09
  
  [MPG123_LINK_DLL]
  
  I guess we should put a platform check into mpg123.h to default to a client build on Windows?
  
  Setting __declspec(dllimport) unconditionally on Windows would break clients that statically link libmpg123.
  
  But apparently it works without?
  
  "Modern" (last decades I think, I can did up details if wanted) MSVC toolchains do work without __declspec(dllimport) in client code when calling functions from a linked import library of a DLL, albeit (IIRC) at a small pointer indirection cost for every function call. HOWEVER, it does not work (silent corruption, without any compiler warning) for data/variables exported from a DLL.
  
  As far as I know, libmpg123 does not export any data but only functions, so client code is fine without having the symbols marked with __declspec(dllimport).
  Demanding/recommending client code to #define MPG123_LINK_DLL when linking against the DLL is also the sane choice for mpg123 (and that is what most other projects do on Windows), but not strictly necessary nowadays. Some projects (like FLAC) invert the logic and require a macro to be defined for static linking, which is less ideal.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Thomas Orgis - 2024-12-11

May you test if the snapshot https://mpg123.org/snapshot/mpg123-1.32.10-dev+20241210193333.tar.bz2 works for you? Without the patches vcpkg added now? I'd intend to release that as 1.32.10 soon.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Martin - 2024-12-23

Hi, sorry for not finding the time to test this before release - I had to build the app on mingw64 in the end, but thank you so much for taking care of it together with the vcpkg people!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Thomas Orgis - 2025-01-04

status: open --> closed-fixed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

"unresolved external symbol mpg123_open" when installing from vcpkg

Release Series

Searches

Help

#374 "unresolved external symbol mpg123_open" when installing from vcpkg

Related

Discussion

Related