On Tue, 8 Oct 2024 at 15:12, LIU Hao <lh_mo...@126.com> wrote: > 在 2024-10-08 18:43, Marius Mikučionis 写道: > > Hi, > > I am using g++-14 from mingw64 from MSYS2 on Windows. > > I am trying to discover the location of C and C++ standard libraries by > > using command `gcc -print-file-name=libstdc++-6.dll`, but it just prints > > the library filename without an absolute path. > > Did it work before? >
Yes! At least from gcc-10 to gcc-13 from mingw worked, and native gcc on Linux continues to work. It's only gcc-14 from mingw does not print the paths to dynamic libraries. I've got tipped that gcc-14/mingw still works for static (.a) libraries, and you found it too. > > `-print-file-name=` is supposed to print a file for linking, but DLLs > aren't meant to be linked, so > it should not give any sensible results. (The fact that DLLs can be linked > directly doesn't justify > that.) > Yes, but it does not specify how linked: statically or dynamically. It is useful in both cases. This feature is important when diagnosing the build system (which library exactly the compiler is picking?), especially if multiple -isystem and -L arguments are provided -- it can get pretty messy. > Instead, this is likely to produce a path to the import library: > > g++ -print-file-name=libstdc++.dll.a > Yes, this works. > > GCC-13 used to print the absolute path, but GCC-14/Mingw does not > anymore. > > Native GCC-14 on Linux (Fedora, Ubuntu, Debian) prints the absolute path, > > but not the GCC-14/Mingw build. > > On Linux, SO files belong in the `lib` directory, but on Windows DLL files > belong in `bin`. And > that's the difference: If you copy libstdc++-6.dll into `lib` then it may > produce something meaningful. > Yes, but I'd rather not mess with the installation (which also assumes root and it would make everything even more confusing). > *Is there an alternative way to figure out the location of the libraries > > used by GCC-14/Mingw?* > > > > Within MSYS2 ldd is actually helpful in displaying what the library > loading > > will load, but it is not available when cross-compiling on Fedora which > > ships mingw-gcc-14 (Ubuntu and Debian ship gcc-13/mingw, which does not > > have this problem). On Linux I use objcdump to inspect the dependencies, > > but it does not print the absolute path. > > On Debian/Ubuntu/Mint, this DLL is installed to > `/usr/lib/gcc/x86_64-w64-mingw32/13-win32/libstdc++-6.dll` for GCC 13 the > win32 thread model (there > is another one for the posix thread model), but it is not a standard DLL > directory. Note the version of your gcc is 13, so it should be fine. > If you attempt > to launch such a program with Wine, it will fail to start. > Yes, wine fails because it does not know about mingw or where to find those libraries. And I need such paths exactly for testing under wine: I add this path to WINEPATH and then wine runs happily. Alternatively one can copy all the libraries next to the executable, but one still needs to know the locations of each library. > > You can get the file name (basename) of a DLL with `dlltool -I`: > > $ x86_64-w64-mingw32-g++ -print-file-name=libstdc++.dll.a > /usr/lib/gcc/x86_64-w64-mingw32/13-win32/libstdc++.dll.a > > $ x86_64-w64-mingw32-dlltool -I > /usr/lib/gcc/x86_64-w64-mingw32/13-win32/libstdc++.dll.a > libstdc++-6.dll > dlltool attempts to create a dll from static library, I get permission denied error on Ubuntu: x86_64-w64-mingw32-dlltool: Can't create .lib file: /usr/lib/gcc/x86_64-w64-mingw32/13-posix/libstdc++-6.dll: Permission denied I am asking for compiler diagnostics, not a workaround. However I don't think there is a reliable way to get absolute paths to > these DLLs. Perhaps you will > have to hard-code these rules: The DLL may be in the same directory as the > import library, or > `../bin/` relative from the import directory. > I can see the workaround, but that is heuristic and I would still not know what path the compiler is actually choosing/finding. I would have to recreate the library search algorithm embedded in the compiler, which may change and thus the solution is brittle. -- Marius _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
