I have the source code of Graphics Gems for DOS.
I try to compile with DJGPP by running make.
It does nothing. It only says "no makefile found".
I am almost sure that I need an older compiler, but what tools and versions do I need so I can build the library and executable files?
Related
Good Morning.
I am compiling Clang, following the instructions here Getting Started: Building and Running Clang
I am on linux and the compilation goes smoothly. But I think I am missing out something...
I want to compile ONLY clang, not all the related libraries. The option -DLLVM_ENABLE_PROJECTS=clang seems doing what I want (check LLVM_ENABLE_PROJECTS here)
If I use the instructions written there, I can compile, but I think I am compiling too much....a build directory of 70GB seems too much to me...
I tried to download the official debian source and compile the debian package (same source code! just using the "debian way" to create a package from official debian source), just to compare...The compilation goes smoothly, is very fast, and the build directory is much much smaller...as I expected...
I noticed in the first link I provided the phrase "This builds both LLVM and Clang for debug mode."...
So, anyone knows if my problem is due to the fact that I am compiling a "debug mode" version? if so, how could I compile the default version? and is there a way to compile ONLY clang without LLVM?
Yes, debug mode binaries are typically much larger than release mode binaries.
Cmake normally uses CMAKE_BUILD_TYPE to determine he build type. It can be set from the command line with -DCMAKE_BUILD_TYPE="Release" o -DCMAKE_BUILD_TYPE="Debug" (sometimes there are other build types as well).
I am trying to cross-compile my Rust project on Mac OS to Linux using cargo build --target=x86_64-unknown-linux-musl.
I installed the binary for Linux + musl cross-compilation on mac using brew install FiloSottile/musl-cross/musl-cross as I would ideally want a standalone binary.
I also installed the target using rustup target add x86_64-unknown-linux-gnu
And I have the following in my .cargo/config:
[target.x86_64-unknown-linux-musl]
linker = "x86_64-linux-musl-gcc"
However, I ran into issues with 2 libraries - sqlite3 and pcap:
= note: /usr/local/Cellar/musl-cross/0.9.8/libexec/bin/../lib/gcc/x86_64-linux-musl/6.4.0/../../../../x86_64-linux-musl/bin/ld: cannot find -lsqlite3
/usr/local/Cellar/musl-cross/0.9.8/libexec/bin/../lib/gcc/x86_64-linux-musl/6.4.0/../../../../x86_64-linux-musl/bin/ld: cannot find -lpcap
collect2: error: ld returned 1 exit status
I was able to solve the sqlite3 linker issue by adding features = ["bundled"] to my Cargo.toml file (similar to what is described here - https://users.rust-lang.org/t/linker-cannot-find-lsqlite3/23230/18) as that likely built it from source (which was great) but when I tried doing the same with pcap, it gave the following error:
the package `myProject` depends on `pcap`, with features: `bundled` but `pcap` does not have these features.
After reading somewhere I also tried (with low hopes) of providing the path to the installed libpcap on mac using RUSTPATH='-L/...' cargo build ... but that resulted, of course in undefined symbol errors.
Any ideas how can I get past this issue and cross compile my Rust project into a statically linked binary on macos to run on linux?
Cross compilation does not magically take care of libraries. You cannot just say "I want musl" and have something take care of all your dependencies.
The error message you are seeing is telling you exactly this: it cannot find libsqlite3 and libpcap.
The reason the error for sqlite disappears is because your sqlite library has a bundled feature, which replaces the linking with a built-in sqlite client. This, however, also requests the pcap bundled feature, which does not exist.
You have two options:
If you do not mind the performance loss in the bundled sqlite client, change your feature definition to target the feature of the dependency requiring sqlite
If you want the raw library itself, you will have to compile it for musl
No matter what happens, you will need to cross-compile libpcap for musl with the default sysroot provided by your musl compiler. As this varies per library, you will need to consult the libpcap documentation. once you have done so, you should be able to use the -lpcap flag, and the error will resolve itself.
I believe my question is similar to this post: Linux: cannot find lgfortran though gfortran is installed.
However, since the suggested answer does not fix my problem, there seems no other choice other than asking it again, for a desperate Linux new comer like me.
Here is the problem. I installed GNU fortran compiler 4.8.4 and can find it in terminal
$ which gfortran-4.8
/usr/bin/gfortran-4.8
and
$ locate gfortran
/usr/bin/gfortran-4.7
/usr/bin/gfortran-4.8
/usr/bin/x86_64-linux-gnu-gfortran-4.7
/usr/bin/x86_64-linux-gnu-gfortran-4.8
/usr/lib/gcc/x86_64-linux-gnu/4.7/libgfortran.a
/usr/lib/gcc/x86_64-linux-gnu/4.7/libgfortran.so
/usr/lib/gcc/x86_64-linux-gnu/4.7/libgfortran.spec
/usr/lib/gcc/x86_64-linux-gnu/4.7/libgfortranbegin.a
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgfortran.a
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgfortran.so
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgfortran.spec
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgfortranbegin.a
/usr/lib/x86_64-linux-gnu/libgfortran.so.3
/usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0
/usr/share/doc/gfortran-4.7
/usr/share/doc/gfortran-4.8
/usr/share/doc/libgfortran-4.7-dev
/usr/share/doc/libgfortran-4.8-dev
/usr/share/doc/libgfortran3
/usr/share/man/man1/gfortran-4.7.1.gz
/usr/share/man/man1/gfortran-4.8.1.gz
/usr/share/man/man1/x86_64-linux-gnu-gfortran-4.7.1.gz
/usr/share/man/man1/x86_64-linux-gnu-gfortran-4.8.1.gz
/var/cache/apt/archives/gfortran-4.7_4.7.3-12ubuntu1_amd64.deb
/var/cache/apt/archives/gfortran-4.8_4.8.4-2ubuntu1~14.04_amd64.deb
/var/cache/apt/archives/libgfortran-4.7-dev_4.7.3-12ubuntu1_amd64.deb
/var/cache/apt/archives/libgfortran-4.8-dev_4.8.4-2ubuntu1~14.04_amd64.deb
/var/cache/apt/archives/libgfortran3_4.8.4-2ubuntu1~14.04_amd64.deb
/var/lib/dpkg/info/gfortran-4.7.list
/var/lib/dpkg/info/gfortran-4.7.md5sums
/var/lib/dpkg/info/gfortran-4.8.list
/var/lib/dpkg/info/gfortran-4.8.md5sums
/var/lib/dpkg/info/libgfortran-4.7-dev:amd64.list
/var/lib/dpkg/info/libgfortran-4.7-dev:amd64.md5sums
/var/lib/dpkg/info/libgfortran-4.8-dev:amd64.list
/var/lib/dpkg/info/libgfortran-4.8-dev:amd64.md5sums
/var/lib/dpkg/info/libgfortran3:amd64.list
/var/lib/dpkg/info/libgfortran3:amd64.md5sums
/var/lib/dpkg/info/libgfortran3:amd64.postinst
/var/lib/dpkg/info/libgfortran3:amd64.postrm
/var/lib/dpkg/info/libgfortran3:amd64.shlibs
/var/lib/dpkg/info/libgfortran3:amd64.symbols
So gfortran seems installed, although I don't understand why 4.7 version is still there after my removing it.
In setting Global Compiler Settings of Code:Blocks, when I choose GNU Fortran Compiler, and its Toolchain Executables, I tried the installation directory as
/usr
/usr/bin
and
/usr/lib/gcc/x86_64-linux-gnu/4.8/
as suggested in the previous post, Code:Blocks tell me
could not auto-detect installation path of "GNU Fortran Compiler".....
More details of compiler configuration is here in the image (Thanks to Mike's suggestion).
And here's the full list of compilers on my computer:
List of Compliers
Your posting shows that you have both gfortran-4.7 and gfortran-4.8
installed under /usr/bin.
Having multiple GCC Fortran compilers (or multiple C or C++ compilers) is
perfectly valid and commonplace. Code::Blocks will allow you configure
as many Fortran compilers as you have got, provided you give them different
names. It's also fine if you just want to configure one of them as the
"GNU Fortran Compiler" and ignore the others.
But in any case, Code::Blocks must be able to unambiguously identify the
installed compiler that you are calling "GNU Fortran Compiler". You
have specified the Compiler's installation directory as /usr/bin
and have left the Program files compiler name as gfortran.
There is no such compiler as /usr/bin/gfortran in your system,
and there is no program called gfortran anywhere in your PATH. You
have /usr/bin/gfortran-4.7 and /usr/bin/gfortran-4.8. As you have
installed both of them, Code::Blocks assumes you want both of them. It
can't tell which one of them you want to configure as "GNU Fortran Compiler".
So:-
Set Compiler's installation directory = /usr/bin
In Program files, change all occurrences of gfortran to gfortran-4.8,
if you want "GNU Fortran Compiler" to mean gfortran-4.8.
OK out.
Default compiler name in 20.3 version was mingw32-gfortran. However, the executable name coming with installation is x86_64-w64-mingw32-gfortran. If this is written in compiler settings. It works.enter image description here
The install file codeblocks-20.03mingw-setup installs the file gfortran.exe into the C:\Program Files\CodeBlocks\MinGW\bin directory. However the Settings>Compiler>toolchainexecutables autodetect function looks for mingw32-gfortran.exe.
To fix this, in toolchainexecutables, change the filename mingw32-gfortran.exe to gfortran.exe in 3 places, then autodetect will find it.
I've spent a lot of time setting up the CUDA toolchain on a machine running Ubuntu Linux (11.04). The rig has two NVIDIA Tesla GPUs, and I'm able to compile and run test programs from the NVIDIA GPU Computing SDK such as deviceQuery, deviceQueryDrv, and bandwidthTest.
My problems arise when I try to compile basic sample programs from books and online sources. I know you're supposed to compile with NVCC, but I get compile errors whenever I use it. Basically any sort of include statement involving CUDA libraries gives a missing file/library error. An example would be:
#include <cutil.h>
Do I need some sort of makefile to direct the compiler to these libraries or are there additional flags I need to set when compiling with NVCC?
I followed these guides:
http://hdfpga.blogspot.com/2011/05/install-cuda-40-on-ubuntu-1104.html http://developer.download.nvidia.com/compute/DevZone/docs/html/C/doc/CUDA_C_Getting_Started_Linux.pdf
To fix the include problems add the cuda include directory to your compilation options (assuming it is /usr/local/cuda/include):
nvcc -I/usr/local/cuda/include -L/usr/local/cuda/lib test.cu -o test
cutil is not part of the CUDA toolkit. It's part of the CUDA SDK. So, assuming you have followed the instructions and you have added the PATH and LIB directories to your environment variables you still need to point to the CUDA SDK includes and libraries directories.
In order to include that lib manually you must pass the paths to the compiler:
nvcc -I/CUDA_SDK_PATH/C/common/inc -L/CUDA_SDK_PATH/C/lib ...
Although I personally prefer not to use the CUDA SDK libraries, you probably will find easier start a project from a CUDA SDK example.
I'm trying to implement an open source library that is built using the GNU compiler. (namely, this: https://github.com/mjwybrow/adaptagrams )
I've tried opening and building that source code using VSC++ 6, but it results in over a thousand errors due to the strict nature of the VS compiler I guess. And rather then go through every error and try fix it myself, I was wondering if it's possible to just include the .lib if it is built with the GNU compiler?
EDIT:
Included in the source code linked above is an autogen.sh file.
mkdir -p m4
autoreconf --install --verbose
automake -a --add-missing
./configure
make
Running that with Cygwin results in a few .a library files to be created, which are unusable in VS. Is it ok to just rename these to .lib files?
I've found some stuff online about how to use GCC and create a DLL, but my problem is that I don't know enough about the GNU compiler or makefiles, or the source code in general to be able to change it right now.
Does anybody have any clues on what exactly I'd need to change to get it right? Or even better, has anyone created a DLL using this source code already that would be able to pass it on to me, or let me know what I have to do?
Or could anyone point me towards a similar library that would be compatible with visual studio?
No; you can however build the .dll file with gcc and use the .dll from msvc (with either a hand-crafted include file or a properly formatted one from the beginning, with platform specific import/export macros on top).