I have downloaded and ran the CUDA 5.0 installer on my Mint 15 64bit distro. After hours of agony adjusting / removing / installing packages, it was able to finish installation - at least that what it said.
I can go run the CUDA samples so I thought hey it's working. However, I just made a new cu file and wanted to compile but it said "nvcc command not found"
I have looked at a topic similar to this here and they are talking about /opt/bin/ directory however on mine, there is no such directory. Does that mean it actually did not install ? It tells me to install nvidia cuda toolkit with apt-get but I am not sure if I should do that.
Also, I did say I ran the CUDA samples fine but I have to say ldconfig /usr/local/cuda/lib64
before I can get it to working. Is there a way to automate that ?
Thanks
You need to add the bin directory of the nvcc compiler driver to your PATH (environment variable), and you need to add the appropriate lib directories to your LD_LIBRARY_PATH environment variable.
For an immediate test, this should be as simple as:
export PATH=$PATH:/usr/local/cuda/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib64:/usr/local/cuda/lib
These instructions should be presented to you at the completion of a successful cuda toolkit install, but it seems your install method may have been roundabout.
To make this "automatic" you may want to investigate one of the methods to add these statements to a script run at login. For example, if you have a .bashrc file in your user's home directory, try editing that with the above commands. It should probably be sufficient to put the above commands at the very end of your ~/.bashrc file if you have one.
Note that Linux Mint is not one of the officially supported CUDA distros, so your mileage may vary.
Related
Sure, I've "chosen the wrong OS," Fedora instead of RHEL or CentOS, but I am where I am and there's no rtmp module in the standard distribution of nginx for Fedora since both RHEL and CentOS DO have the rtmp module available as a standard package.
So, I downloaded the source and did a build. While the call make install does the build (and I didn't see any errors in the 817 lines of output), it DOES NOT do the installation?!
At first I went down the wrong garden path, which is not totally wrong (see below as "Part II") but while writing "Part II" for this posting, I realized that I can't even find ANY evidence that it compiled ANY of the source for the rtmp module?! I followed the directions in the module's github readme file.
Of course, I kept a log of the run - too long to post here.
Having decades of coding experience I knew to check for a Makefile for that code and didn't find any?! STRANGE, right?
If anyone asks for info from that log, I have it and will provide it, but IDK what you may want to see from it.
Part II
I figured the installation didn't happen because the source code is written generically and doesn't pay any attention to the OS it's being installed on, and that's what "packaging" is all about and what package maintainers have to deal with...
I don't really have time to learn ALL the ins and outs of these packages, but I do know that the standard nginx packages provide these modules:
usr/lib64/nginx/modules/ngx_http_perl_module.so
usr/lib64/nginx/modules/ngx_http_image_filter_module.so
usr/lib64/nginx/modules/ngx_mail_module.so
usr/lib64/nginx/modules/ngx_http_naxsi_module.so
usr/lib64/nginx/modules/ngx_stream_module.so
usr/lib64/nginx/modules/ngx_http_xslt_filter_module.so
usr/lib64/nginx/modules/ngx_http_vhost_traffic_status_module.so
However, I don't see the compilation creating ANY .so files, much less moving them where they go on Fedora (the default is apparently /etc/nginx/modules). Further, the log output directed me to look to /usr/local/nginx, and there no .o or .so files at all but rather a single binary. That's fine, but doesn't help me, I presume, unless I want to screw around with moving files from where they're "expected" from the OS vs nginx point's of view and that sounds to me like a time-sink of massive proportions.
However, this IS a one-off installation at the moment and I'd rather not have a lot of pain whenever this box (and likely others to follow if this works) needs an upgrade. So, I found this gem of a blog posting. It touches on this problem but also seems rather involved as I don't fully grock it yet.
If I could simply learn how to build the correct file, which I presume is intended to be (once installed):
/usr/lib64/nginx/modules/ngx_rtmp_module.so
...from the .c source files, then I'm pretty sure I could "figure it out from there."
(Another possibility might be to find a way to prove from some sort of analysis that the GetPageSpeed people didn't alter the source when providing their package. Or, perhaps I could convince the package maintainer to include the rtmp package in with the standard packages available for Fedora, but, well, at best that's a long wait.)
It turns out that the build from source skips the .o and .so file stages and just builds an executable.
It's not set up for running in the normal, modern Fedora environment, however, as already noted above.
Not finding another answer and wanting to move on to other things, I simply got this from-source version working and it wasn't that hard. Note that this presumes you've installed the standard nginx package(s), which in this case hook in your man pages, systemd interfaces and so on so you can manage it as usual. In your favorite shell, as root:
# First, for my own sanity:
#
cd /etc
mv nginx nginx.from_FC_distro
ln -s /usr/local/nginx
cd /usr/local/nginx/logs
mv error.log error.log.orig
ln -s /var/log/nginx/error.log
#
# Now, get it to run and STAY running:
#
cd /usr/sbin
mv nginx nginx.from_FC_Distro
# Then EITHER this:
cp -p /usr/local/nginx/sbin/nginx /usr/sbin/nginx.from_src
ln -s nginx.from_src nginx
# OR this:
ln -s /usr/local/nginx/sbin/nginx
# Either vi or the echo works:
# vi /etc/nginx/conf/nginx.conf
echo "pid /run/nginx.pid;" >> /etc/nginx/conf/nginx.conf
#
# Finally:
systemctl enable nginx.service
systemctl start nginx.service
And now you have a running installation of the nginx server with whatever config you set up in the config file WITH the rtmp service! AND, you can manage it as usual. Upgrades aren't so hard, either, just don't bother with upgrading the nginx package the usual way. I'm sure the script-kiddies can figure out how to script it based on this article.
Everytime I try to build and run a program, including the standard 'Hello world!' nothing happens, I get:
==== Program exited with exit code: 0 ====
Time elapsed: 000:00.000 (MM:SS.MS)
Press any key to continue...
At the bottom it says:
'ming32-make' is not recognized as an internal or external command, operable prgram or batch file.
I have Codelite version 16 on Windows 10. I also have MinGW installed to C: and have edited the Environment variables to include C:\MinGW\bin
However, in command prompt gcc --version shows me the gcc version in C:\Users\me> and not C:\MinGW
I don't know if this is relevant or not.
All the other results seem to suggest a compiler not found problem, but this does not seem to be my case. Thanks in advance.
This is what I have installed at the moment. Can I get 'make'from one of the other files?
The Installed files
Looks like you either don't have ming32-make.exe or it can't be found.
Also I notice you still use old MinGW. I would recommend switching to newer MinGW-w64 (which supports both Windows 32-bit and 64-bit).
The standalone build from https://winlibs.com/ does include ming32-make.exe, and since you can just unzip it (no installation needed) you can try it without removing the old MinGW. Just make sure you don't have anything in your PATH variable to avoid running programs from the wrong location.
ming32-make.exe is either not installed or can't be found on your Environment variable PATH.
No, there is no mingw32-make in that bin folder. When I used the Installer originally I only selected: mingw32-gcc-g++-bin although there were other bin files. Where can I get it?
mingw32-make is outdated.
See How to compile makefile using MinGW?
If you are having problems with mingw, I would recommend using MSYS2 or a package manager like Chocolatey.
Just get rid of the previous installation first. Not mandatory but prevents confusion and storage drain due to multiple copies of mingw.
To install MinGw using chocolatey, run cmd as admin and use
choco install mingw
For make
choco install make
What worked for me was also installing mingw32-base-bin from the Installer (see second option in image in the original question).
The installation tutorial I was following did not mention installing this.
I've decided to leave this here as an answer in case someone else runs into a similar problem.
MSYS is a good option for compilers in recent CodeLite or VS-Code installation. https://www.msys2.org/.
Once you downloaded the compiler using the following steps from the installer but still have the problem with the make then follow these steps:
Reopen the MSYS2 terminal from your windows if that is previously installed.
Run the command pacman -S --needed base-devel mingw-w64-x86_64-toolchain
You will be asked to select the option from the list. You should select the option which refers to mingw-w64-x86_64-make.
Once the installation is successfully done, then open CodeLite settings->Buid Settings and check your Make file location. If that is empty or showing an unknown location then click the three dots at the very right of that box. The browse and navigate to location or where you installed the make by pacman. In my case it is C:/msys64/usr/bin/make.exe.
Click Apply and Save.
Now it might be needed to create a fresh workspace and re-run your code.
I want to build FuTTY.
The original author uses Visual Studio, I want to avoid that. I found out that apparently I have to:
Add MinGW/bin and MinGW/msys/1.0/bin to the PATH
run perl mkfiles.plto restore some missing makefiles
Remove -mno-cygwin from Makefile.cyg
Add XFLAGS = -DCOVERITY to Makefile.cyg
run make -f Makefile.cyg putty.exe from the windows directory
This works for building the original PuTTY, but is not enough for FuTTY.
It complains that KEY_WOW64_32KEY is undeclared. When I googled that, I found that apparently this means you need MinGW-W64.
At this point I'm making wild guesses, but I think the selector shown below means that the MinGW-W64 project is about making all kinds of toolchains run on Windows 64 bit and if I want something that works with PuTTY's MinGW makefile, I need this:
Right? So after downloading that, I am presented with questions I cannot answer:
I'm using more handy tool chain distribution MSYS2
I have access to a shell account at University as a user but with no root privileges. The server is running Ubuntu 8.04 - Hardy. I wish to use Clang as my C compiler for next semester's Unix programming course. GCC is installed but not Clang, and the University's IT dept has, as expected, declined to install Clang on the system.
Is it possible to run Clang from my home directory as user? Presumably I would need to compile from source. I need it to compile only C. I don't need C++ or Obj C for this course.
You can use the autotools installation method by running ./configure --prefix=$HOME (or some subdirectory of your home directory if you prefer) or by using the CMake build and installation with the CMAKE_INSTALL_PREFIX set to some directory under your home. The former is documented here, merely add the --prefix flag to the configure step, and run 'make install' at the end.
Once installed, put the bin subdirectory of whatever prefix you used into your PATH environment variable, and you should be good-to-go. This is actually the way I use Clang regularly as a developer of Clang and LLVM.
For reference, this is definitely a mode of installation and use that we (Clang developers) want to support. If you run into issues, don't hesitate to file bugs or reach out for support on our email lists or IRC channel (#llvm on irc.oftc.net).
With free software, you can always configure it and (if needed) patch and improve it to suit your needs. However, building a compiler (be it GCC or Clang) requires a lot of resources (disk space, several gigabytes, and also RAM & CPU time), and some of your time and efforts.
Clang building and installation is documented here. I guess that its configure script -assuming it is similar to GCC's one- accepts arguments like --prefix (which you could e.g. set to $HOME/pub). You might need to build also the required dependencies.
As the project appears to use autotools you can alter the installation destination with command line parameters to the configure program (e.g. --prefix=$HOME/clang). Running ./configure --help and reading the INSTALL text file will give you more details.
If not already installed, you also need to build LLVM, which is the parent project (Low Level Virtual Machine) as well. Installation instructions for both are available at the clang website.
I'm trying to compile a c programming package (thc-ipv6-0.7) on Linux Redhat 2.6.9-42.ELsmp and it's complaining that it can't find "linux/string.h".
From google, I learned that this is part of the "kernel-headers" package.
If I do "rpm -qa | grep kernel"
It shows that "kernel-devel" is installed (which I think I need), but not "kernel-headers".
A "find / -name string.h" reveals string.h is in fact on the system, in many places, including "/usr/include".
I tried adding "-I/usr/include" to the make file, but got the same error.
My question is, do I need to install "kernel-headers", and if so, where do I find it, and what version?
Normally, you have to install the version of those headers which correspond to the version of the kernel run by the system on which you'll execute the program. In your case in you want to run locally, 2.6.9-42.
The message complains about "linux/string.h" and not "string.h", so you have add a directory having linux as subdirectory.
I'm not knowledgeable enough about redhat to know how to install them (probably an rpm command) and where they will be installed (with Debian and derivatives put them you have to use -I/usr/src/linux-kernel-version/include").