I have a programming language I'm fiddling with and it calls clang to link the bitcode file it emits. (Perhaps there is a better way to do this all together?) I've been using Visual Studio Code to debug it and it has mostly worked great.
I recently upgraded llvm. At that point, builtin osx clang was complaining about not recognizing a bitcode construct. So I installed clang part of llvm with brew. This looks to work for the compiler but fails to call the linker.
When I run a debug session I get this in the debug window:
clang-6.0: error: unable to execute command: Executable \"ld\" doesn't exist!
However, if I run from the embedded terminal it works fine.
It seems like clang is trying to explicitly expand the location of ld rather than using builtin path resolution. Something in VSCode's C++ debugger launched environment is causing issues with it.
Some supporting bits of diagnosis (trying to keep this a bit short for now...).
When run from the debugger:
whereis ld works and emits...
/usr/bin/ld
env emits what looks like a wrapped environment...
PWD=/Users/<snipped>
SHLVL=1
_=/usr/bin/env
echo $PATH emits...
/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.
And clang tries to link it runs "ld" and says...
clang-6.0: error: unable to execute command: Executable "ld" doesn't exist!
When run from the embedded terminal on the other hand:
whereis ld works and emits...
/usr/bin/ld
env emits...
a metric ton of stuff including
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin
echo $PATH emits...
/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.
And clang tries to run "/usr/bin/ld" which works fine.
I realize this may be a clang ld lookup bug (not correctly expanding _=/usr/bin/env??). Unfortunately A) I don't know very much about OSX environment expansion B) if VSCode C++ debugger is using some sort of standard OSX environment jujitsu or not C) not sure how to debug clang run from within an existing VSCode debugger session D) don't know how to emulate the VSCode debugger environment setup to get started unravelling the ball of yarn.
I think I've upgraded OSX/XCode that I'm now unblocked (using the builtin clang compiler from within the VSCode debugger works again). I figured I'd raise this anyway in case I can get a problem fixed or at least learn something.
Any thoughts/suggestions?
Thanks,
Adrian
Related
I am new to Linux environment, we have task to migrate a Windows wxWidgets(version 2.4.2) GUI application to Linux platform(RHEL8 or 8.3).The application is successful on Visual studio 2017&2019(Compiler MSVC++ 14.1 and 14.2) using the wxWindows-2.4.2(very old one). But when i try to build wxWindows2.4.2 on Linux( g++ (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5))
../configure --with-gtk=2
at configuration stage process stopped saying
checking for toolkit... configure: error: Please specify at most one
toolkit (maybe some are cached in configarg.cache?)
I tried by installing "Development Tool" on Linux but getting same thing.
Source: https://github.com/wxWidgets/wxWidgets/archive/refs/tags/v2.4.2.zip
You can successfully run the configure phase by first performing dnf install gtk2-devel, and then configuring with ./configure --enable-gtk2.
However, (not surprisingly), wx 2.4.2 will not successfully build on RHEL8 (I tried); there will be a bunch of compilation errors. Those are not impossible to fix, but I wonder if that's worth the trouble – there probably would be runtime errors and/or misbehaving GUI components at the next stage.
While I understand your strategy of choosing the old wx version that the application is known to work with on Windows, it seems to be the hard way in this case.
On macOS Mojave with Xcode 11.3, I have an Autotool based thirdparty lib builds just fine when running my build script in Terminal, but fails when run in Xcode Run Script step as ./"$BuildScript"
Showing All Messages
/configure:1:1: C preprocessor "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cpp" fails sanity check
This seems to correspond to my CPP variable in the script
export CPP=$(xcrun --find --sdk "${SDK}" cpp)
But I can't figure out why running the script AS IS in Terminal does not have the issue.
Does it have anything to do with Xcode's environment variables?
How should I fix this?
I've tried to switch to different compiler executables to no avail.
EDIT 1
This seems to be related to linking to the mono library, once I remove any kind of reference to mono code and remove the linking to the library from my CMakeList.txt file, debugging works as expected.
EDIT 2
Okay, I've discovered something interesting. This actually might not have anything to do with how I am linking libraries, it appears to be directly related to how I am initialising a class in my unit test. For whatever reason, if I use my normal syntax of TypeDeclaration variableName; the unit test fails immediately with the error code 0xc0000135, but if I change it to read TypeDeclaration variableName(); the code will run. Only problem is that I then get a warning stating empty parenthesis interpreted as a function declaration. I came from linux using g++ to compile my code and there was never an issue, now all of a sudden trying to compile on windows using cygwin or mingw means I can't use the normal standard c++ syntax to actually do work...
Edit 3
I've discovered that this issue is occurring because the libraries I am dependent on aren't actually being copied into the build directory of my unit test project. If I manually copy the required libraries into my build directory debugging works as expected, will need to learn how to express this requirement in CMakeList.txt
More Details
CLion Specifics
CLion 2018.3.1
Build #CL-183.4588.63, built on December 5, 2018
JRE: 1.8.0_152-release-1343-b16 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0
Toolchain Settings
Cygwin 32 bit version 2.11.2
CMake version 3.13.1
Make version 4.2.1
gcc version 7.3.0
Debugger Cygwin GDB version 8.1.1
catch.hpp for unit testing.
Problem
When debugging a unit test, CLion reports the following error:
During startup program exited with code 0xc0000135.
Google returns a lot of Qt and netbeans related results, everyone suggests to add C:\mingw\bin to the system PATH variable. However I am not using mingw I am using cygwin. I tried adding C:\cygwin\bin to my PATH directory but that does not help. I also tried switching toolchain to use mingw to see if that would help. but the same problem occurs with debugging.
Not sure what else I can do to proceed in resolving this one, any ideas would be most welcome.
I've got a Python program that calls Fortran routines. These Fortran routines are wrapped with f90wrap (https://github.com/jameskermode/f90wrap), and I've verified that the setup works correctly on Linux and Mac OSX. I'm now trying to get the setup to work equally well on Windows (because I collaborate with people who cannot sometimes switch to Linux).
I've got gfortran working through a MinGW installation and verified that Fortran programs compile and run without errors. I've also verified that a Python 2.7 installation works without issues, and was able to use pip to add numpy, matplotlib and scipy modules without issues. Both MinGW and Python are 64-bit, running on Windows 10. I've also got CMake to create Makefiles that compile standalone fortran programs using mingw-make, so the only part left (to get things working on Windows) is to make sure the Python wrapper for Fortran-90 works. That's where I ran into some issues.
I'm running mingw-make in Powershell (which executes in cmd.exe, I believe).
Q1: The pip installation for f90wrap failed with an absolute path/relative path error (https://github.com/jameskermode/f90wrap/issues/73)
A1: I downloaded the source and ran "python setup.py install", and that got stuck as well. I ran into a "multiple_definition" error with Windows 10, Python 2.7 and mingw-w64.
F:/Programs/mingw/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-atonexit.o):atonexit.c:(.text+0xc0): multiple definition of atexit' F:\Programs\Python\libs/libmsvcr90.a(deoks01081.o):(.text+0x0): first defined here F:/Programs/mingw/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-mingw_helpers.o):mingw_helpers.c:(.text+0x0): multiple definition of_decode_pointer'
F:\Programs\Python\libs/libmsvcr90.a(deoks00231.o):(.text+0x0): first defined here
F:/Programs/mingw/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-mingw_helpers.o):mingw_helpers.c:(.text+0x10): multiple definition of `_encode_pointer'
F:\Programs\Python\libs/libmsvcr90.a(deoks00241.o):(.text+0x0): first defined here
collect2.exe: error: ld returned 1 exit status
error: Command "gcc -g -shared build\temp.win-amd64-2.7\Release\f90wrap\arraydatamodule.o build\temp.win-amd64-2.7\Release\programs\python\lib\site-packages\numpy\f2py\src\fortranobject.o -LF:\Programs\Python\libs -LF:\Programs\Python\PCbuild\amd64 -lpython27 -lmsvcr90 -o build\lib.win-amd64-2.7\f90wrap\arraydata.pyd" failed with exit status 1
I have installed the latest LLVM svn trunk using cmake (this is the first time I have used cmake to build LLVM).
The problem is that when I try to make the Hello pass from the LLVM tutorial, it compiles fine (a .so file is created), but the opt tool is unable to load it. It fails with the following message
$ opt -load ./Hello/libLLVMHello2.so
Error opening './Hello/libLLVMHello2.so': ./Hello/libLLVMHello2.so: undefined symbol: _ZTIN4llvm12FunctionPassE
-load request ignored.
I am using cmake, and following the instructions at http://llvm.org/docs/CMake.html#cmake-out-of-source-pass
I have some other passes lying around, but I do not want to use the cmake build system until this problem is solved.
Any suggestions would be helpful. Thank you!
You built your Hello pass with rtti enabled, while LLVM is built without.