Open fiwippi opened 4 years ago
Hm, can we somehow get g++ to be super-verbose about its linking decisions?
Hey so I managed to get verbose output for the g++ linker and I have identified the error sorta although I am not sure what it means.
The ld looker searches for libportuadio.a
and libportaudio.lib
as opposed to .dll
. I don't really know what this means. When compiling without an ui
code, the linker also searches for .dll
files which in turn means it actually finds the .dll
file.
I omitted the full output because it is meaningless and very large. If you would like it I can include it below.
Edit: This issue might be a duplicate of #347
Edit: Edit: After using the -Bdynamic
flag as suggested in the issue which #347 references, portaudio is found but not found at the same time. I am so confused. The output is given below:
attempt to open C:\TDM-GCC-64\lib\/libportaudio.dll succeeded
C:\TDM-GCC-64\lib\/libportaudio.dllC:/TDM-GCC-64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lportaudio
collect2.exe: error: ld returned 1 exit status
I don't understand why it would be trying to do this but I'm betting it's trying to only use static libraries OR dynamic libraries. I wonder if specifying both -static and -dynamic or -Bdynamic before the respective libraries will do it. If that doesn't work, I wonder if the grouping arguments (whose names I don't remember) can be used to make some libraries static and some dynamic.
I found a static version of the dlI needed which meant ui stopped causing problems.
Thanks. I will close the issue now.
Then yes, that is what's happening. This is worth investigating, but I'm somewhat sure it's me doing something wrong.
Hey, I did some more research into why the problem was occuring. Essentialy, I was adding a -Bdynamic -lportaudio
option in the command line options. Instead of making g++ linker look for a dynamic file instead of a static file, it simply added the dynamic version of the file to the list of files it was searching so that it was looking for portaudio.lib
and portaudio.dll
. This was solved by removing the -Bdynamic
flag and then simply providing the static library.
Hopefully this helped at all. Thanks
Yeah, but there's no reason why we shouldn't allow a mix of static and dynamic dependencies for different projects. I'm pretty sure I'm doing something wrong, and I know the GNU linker has grouping options specifically for this purpose, but I'll have to investigate.
Hi,
Just as a preface, this issue might be related to #326 and #265
So when I compile a go script using the portaudio library,
ld
is able to find the portaudio.dll. In the same way, when compilingui
code, go is able to compile it. However, when I try to compile portaudio and ui code,ld
is not able to find the portaudio dll.After checking the verbose output, the difference is that when it does not work, g++ is used instead of gcc when calling the external linker.
What I don't understand is that when calling
ld
from the command line with the-L
flag to specify the linker library, it is able to find the portaudio dll, But when compiling with go build, the linker is not able to find the dll and it is confusing the hell out of me haha.For reference, this is the failed build script:
Go Env
For reference, I am using the TDM-GCC compiler