On Wed, 9 Oct 2024 at 03:06, LIU Hao <lh_mo...@126.com> wrote: > 在 2024-10-08 23:00, Marius Mikučionis 写道: > > 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. > > The cause of this issue is that DLL isn't actually 'linked'; it's the > import library (.dll.a) that > is linked by the linker, and the DLL is loaded by the operating system > which GCC has no idea about. > The DLL doesn't have to exist (like in the Debian case) and it doesn't > affect linking.
> However the import library only provides the file name of the DLL, rather > than an absolute path; so > there is no way to get that information. > Actually, it does, the dynamic library has to exist during compilation. Otherwise the compiler breaks with the message: $ x86_64-w64-mingw32-g++ -o use_fn.exe use_fn.cpp -L. -lfn /usr/lib/gcc/x86_64-w64-mingw32/14.1.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lfn: No such file or directory collect2: error: ld returned 1 exit status I understand that theoretically the compiler does not need the dynamic libraries and they can be replaced at any time, but gcc checks at least the symbols at compile time: x86_64-w64-mingw32-g++ -o use_fn.exe use_fn.cpp -L. -lfn /usr/lib/gcc/x86_64-w64-mingw32/14.1.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/ccvrfuD9.o:use_fn.cpp:(.text+0x13): undefined reference to `fn2' collect2: error: ld returned 1 exit status > > Yes, but I'd rather not mess with the installation (which also assumes > root and it would make > > everything even more confusing). > > > > 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. > > I was not suggesting you do it. It was a bad example to describe something > which 'works by accident'. > > It's not because it's GCC 13; it's because the DLL happens to be in the > same directory with the > import library, where GCC searches for libraries. > > In this case it's possible to print non-libraries in that directory: > > $ x86_64-w64-mingw32-g++ -print-file-name=g++-mapper-server > /usr/lib/gcc/x86_64-w64-mingw32/13-win32/g++-mapper-server > That's a nice feature: it can be used to discover other tools within the toolchain. > 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 > > Did you mistake `-l` (lower L) for `-I` (capital I)? (I made this mistake > too.) > Yes, you are right, my bad. > 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. > > As explained in the first paragraph, the linker doesn't actually use the > DLL. > I disagree, GCC needs all the libraries to check that the symbols are resolved. There may be changes in GCC that have altered this behavior; I suggest you > have a look at GCC git log. > It looks like a packaging issue: under Linux (and mingw GCC <14), the system libraries are in one place, so there is nothing special, but under mingw specifically GCC=14 they are now in two places (lib and bin). Perhaps that `bin` directory needs to be added to when -print-file-name is searching for libraries, because clearly the compiler uses all those libraries when resolving the symbols (or perhaps the list of system symbols is precomputed/cached during installation -- again, packaging) Right now I do not have time to dig into git logs, so perhaps next week. Thank you for looking at it! -- Marius _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
