I've been using clang successfully on Windows XP and Windows Vista using the 'experimental' builds for MinGW, but now that I try on my new Windows 7 64-bit laptop it simply crashes. Even if I just run "clang++" or "clang" it crashes, and I can't figure out how to get windows to give me more detailed crash info (I will edit that in if I can). I've redownloaded clang and reinstalled MinGW, and I've tried running clang.exe in compatibility mode, but it still doesn't work. This is the first time I am using it on 64-bit, I hope that's not the issue (if it is, I still have another computer I can use).
I've looked around and can't find anyone else having this same problem with clang crashing before even giving any output or processing any input, I really feel lost.
This has now happened multiple times on various system and I have found the solution. Reinstall MinGW using the prepackaged files, the 'latest' ones have a tendency to be unstable in relation to clang. Make sure you haven't also installed a newer version of gcc on top of the MinGW installation, as that will cause issues too.
Related
I'm developing and building applications for a various amount of platforms (linux x86, x86_64, arm, aarch64, sparc64, mips, powerpc, macos x86_64, freebsd x86_64, solaris x86_64 and of course Windows) and I was using a very old linux box (2014 Ubuntu) for all this cross-compilation.
I've recently decided that it was more than time to move to a more updated build environment as many tools were obsolete and could not be updated, so I've moved everything to a Ubuntu 22.04. All worked fine but then I hit the "glibc version hell" when I tried to run that on other boxes as glibc on that buildbox is 2.35.
So I've tried to get older glibc to compile and link against these as I'd really like to avoid linking everything static. But now, all the gcc that are build with Ubuntu have been with a "--with-sysroot=/" which, AFAII means I can't do anything. The --sysroot option is ignored by gcc which uses / for sysroot, no matter what.
I've seen a few answers saying "use old box to build" and that seems really insane to me. On my Mac or Windows, I can chose minimum (old) target platform, even if I build on W11 or Monterey. And obviously, the reason WHY I move to a new buildbox is to NOT use an old one and be stuck with obsolete tools :-).
I can probably use again ct-ng and rebuild all compilers, including native ones, but that seems really an overkill. Anybody with a better solution?
Thanks!
Seems that there is really no solution for what I'm looking for. I ended up almost re-inventing the wheel while trying to manually installing glibc. It was a faster option to use ct-ng and install cross-compilers from there, not using the stock ones provides with my distro.
I am trying to install the CUDA toolkit in order to be able to use Thundersvm in my personal computer.
However I keep getting the following message in the GUI installer:
"You already have a newer version of the NVIDIA Frameview SDK installed"
I read in the CUDA forums that this most probably results from having installed Geforce Experience (which I have installed). So I tried removing it from the Programs and Features windows panel. However I still got the error, so my guess is that the "Nvidia Corporation" folder was not removed.
In the same question, they also suggested performing a custom install. However I could not find any information on how to do a custom install of the CUDA toolkit. I would really appreciate if someone could explain how to do this custom install or safely remove the previous drivers. I thought of using DDU but I read that sometimes it may actually lead to trouble.
I had the same problem while I was trying to get TensorFlow to use my NVIDIA GTX1070 GPU for calculations. Here's what allowed me to perform the CUDA Toolkit installation on my Windows 10 machine.
As the error message in the installer says - you already have a newer Frameview SDK installed. It was the case for me.
Go to Settings/Uninstall or modify programs.
Remove the NVIDIA Frameview program. It should be there with GeForce Experience, PhysX, etc.
Uninstalling only this NVIDIA program didn't cause any driver problems for my machine and I was able to progress through the CUDA Toolkit installation.
I just met the same problem and fixed it now.
This problem occurred because you chose the default installation configuration, which might contain many installed parts. In my situation, I have installed NVIDIA Nsight Compute, which is the culprit during the first few installs.
Unchecking the redundant parts should be helpful.
I'm trying to configure CLion with Cygwin, but I'm having trouble with CMake. The program says that the bundled version doesn't work in that environment and that the CMake from Cygwin is outdated (needs a newer version). However, I tried installing an independant CMake but then the program says it isn't compatible with Cygwin. How do I fix this?
screenshot
I'm teaching a C++ programming class this semester. All of my students were able to successfully install/configure CLion without too much trouble. Most of them are on Windows boxes, Win7 and Win10.
In my instructions, I referred them to this video, which was the best I could find: https://www.youtube.com/watch?v=i2h_976SpV0
Some of the students were missing the debugger the first time they tried this. In the cygwin installer, the number of check boxes is enormous and many of the names are remarkably similar. When we went back through and re-ran the installer, in each case we were able to find a place where they had checked the wrong box.
So my recommendation would be re-run your cygwin installation after watching the video once through. Then go back to the frame in the video where he shows all his checked install options and very carefully compare your checked boxes against the presenter's.
Good luck!
I'm running Windows 7 Pro, SP1 on a Dell Precision M2800 (I know it's out of date).
My VMWare Workstation version is 11.1.4 build 3848939. Right now I'm using it primarily for a VM with Windows 7 and a bunch of (latest) Rockwell/Keyence software.
I'm using CodeBlocks version 16.01 to compile C++. Packages I'm using in my code include various SDL libraries and the standard stuff.
The issue I'm having is repeatable for me:
I start both VMWare and CodeBlocks running on my host machine. I compile and test code in CodeBlocks while I wait for Rockwell to finish compiling/uploading/etc.. After a couple of times compiling and running programs with CodeBlocks, my host OS will lock up for a long time (more than an hour). I haven't waited long enough to see if it ever unlocks on its own.
The work-around I'm using right now is to just not use those programs at the same time. I'm not necessarily looking for a solution, (because I anticipate that everyone will just tell me to update Windows), although solutions are fine. I'm looking for information about the root cause. Anybody have ideas about why this might be happening?
Thanks in advance.
I have done a little work on lazarus' free pascal. So when a client asked me to write an application for a mac, after the initial, "it can't be done" stage. (followed by an asp.net maybe stage) i thought about writing it using lazarus.
Question is. I have only a virtual machine running mac OSX, this means that i do not really want to develop on the mac. However, i just cannot seem to get the applications that i have written in lazarus on windows to work on the mac. I have tried the deployment using the Lazarus Wiki and the MACOS folder is empty and so when i put it on the mac it doesn't run the application.
What is the best way of doing this or am i barking up the wrong tree?
It seems you want to do cross-compiling, which is theoretically possible, but may not be practical, for the reasons mentioned by Marco above.
As an alternative, you could install XCode, FreePascal, and Lazarus on a MacOX machine. You could still do your development and some testing on Windows/Linux. When you hit a certain milestone, you can copy your source code to the Mac and compile your application to test and give to the user.
Even if it were possible to easily cross-compile, there some minor differences between platforms, so (especially if it's a GUI app), you would want to test it on an actual MacOS box before giving it to the client.
I've taken the route described by Noah - and I was incredibly surprised that after about three weeks development on Windows, it took about 10 minutes to get the application running on the Mac.
My route was to install Xcode 4.3 on an old Mac Mini running snow leopard, then install Lazarus using the fink version as described here. This took a while but was done in an evening.
Then I just copied my folder across to the Mac, opened the lpi on the Mac, compiled it. It failed so I removed a windows references, recompiled, and it was working. I was truly amazed.
What linker and assembler do you use to generate binaries? To my best knowledge the linker for recent OS X versions is not available in source.
Afaik what you want (crosscompiling to Mac) is not possible for recent versions (and I've done it for PowerPC myself in the past).
The easiest is to use the Unix "file" command on the binary to see what is generated, and make sure it reads something with "MachO" in it. Easiest is if you have a Linux install (where this command is pretty standard), but versions can be found for windows too (cygwin, mingw and 3rd party)