while compiling in FreePascal 3.0.0 it shows this error : Fatal: You need ObjFpc (-S2) or Delphi (-Sd) mode to compile this module.
Your code is then probably for a Delphi like mode, while the default is a Turbo Pascal mode. Set one of the selected parameters, or use {$mode to do it in source. See the FPC manual e.g. this topic for details for both the concept of compiler modes and the parameters and directives
Related
I am working on an MPI application for scientific computing. I am working on our distribution process, and it raise the question of the version of the MPI.
I read at some places on the net that MPI should be built with the same compiler suite as the application, but nothing really explaining why.
So I wonder what defines a version of MPI, once it has been compiled? Is it just the version of the source package, or is it the version of the source package plus the compiler suite and its version that has been used to compile MPI?
The version of the MPI implantation is an absolute must. A typical example being an type having changed between versions.
You should also compile all involved libraries - particularly MPI - with the same compiler version. A typical example are compiler-specific libraries. One compiler replaces a call to memcpy with a built-in optimized version. If you try to link with a different compiler, that doesn't provide that optimized function in it's library, you get a linker error. System libraries are usually fine, but for highly optimized builds as well as C++ codes, these kinds of library ABI (application binary interface) incompatibilities are common and very painful.
I am a newbie in OpenCL stuffs.
Whats is the best way to compiler an OpenCL project ?
Using a supported compiler (GCC or Clang):
When we use a compiler
like gcc or clang, how do we control these options? Are they
have to be set inside the source code, or, likewise the normal
compilation flow we can pass them on the command line. Looking at the Khornos-Manual-1.2, there are a few options provided for cl_int clBuildProgram for optimizations. :
gcc|clang -O3 -I<INCLUDES> OpenCL_app.c -framework OpenCL OPTION -lm
Actually, I Tried this and received an error :
gcc: error: unrecognized command line option '<OPTION>'
Alternatively, using openclc:
I have seen people using openclc to compiler using
a Makefile.
I would like to know which is the best way (if
there are actually two separate ways), and how do we control the
usage of different compile time options.
You might be aware but it is important to reiterate. OpenCL standard contains two things:
OpenCL C language and programming model (I think recent standard include some C++)
OpenCL host library to manage device
gcc and clang are compilers for the host side of your OpenCL project. So there will be no way to provide compiler options for OpenCL device code compilations using a host compiler since they are not even aware of any OpenCL.
Except with clang there is a flag that accept OpenCL device code, .cl file which contains the kernels. That way you can use clang and provide also the flags and options if I remember correctly, but now you would have either llvm IR or SPIR output not an device executable object. You can then load SPIR object to a device using device's run-time environment(opencl drivers).
You can checkout these links:
Using Clang to compile kernels
Llvm IR generation
SPIR
Other alternative is to use the tools provided by your target platform. Each vendor that claims to support opencl, should have a run-time environment. Usually, they have separate CLI tools to compile OpenCL device code. In you case(I guess) you have drivers from Apple, therefore you have openclc.
Intel CLI as an example
Now to your main question (best way to compile opencl). It depends what you want to do. You didn't specify what kind of requirements you have so I had to speculate.
If you want to have off-line compilation without a host program, the considerations above will help you. Otherwise, you have to use OpenCL library and have on-line compilation for you kernels, this is generally preferred for products that needs portability. Since if you compile all your kernels at the start of your program, you directly use the provided environment and you don't need to provide libraries for each target platform.
Therefore, if you have an OpenCL project, you have to decide how to compile. If you really want to use the generic flags and do not rely on third party tools. I suggest you to have a class that builds your kernels and provides the flags you want.
...how do we control these options? Are they have to be set inside the source code, or, likewise the normal compilation flow we can pass them on the command line.
Options can be set inside the source code. For example:
const char options[] = "-cl-finite-math-only -cl-no-signed-zeros";
/* Build program */
err = clBuildProgram(program, 1, &device, options, NULL, NULL);
I have never seen opencl options being specified at the command line and I'm unaware whether this is possible or not.
I am a student in Computer Science, and I am learning programming with Pascal.
I have found an interesting Pascal compiler, P4 (http://homepages.cwi.nl/~steven/pascal/).
To know more about Pascal, I am trying to compile their source code, but I failed.
In this web page, they said:
Compile pcom.p and pint.p with a Pascal compiler. You obviously have to have a Pascal compiler already. This gives you a Pascal compiler (pcom) that produces P4 code, and an interpreter (pint) that runs P4 code.
To use the compiler, run pcom with the Pascal program as standard input. This produces any diagnostics on standard output, and its code on a Pascal file that is called prr. Check with your Pascal compiler how this gets assigned to a file in the filestore. You may have to change the lines 'rewrite(prr)' in pcom.p and pint.p and 'reset(prd)' in pint.p for your compiler, for instance to "rewrite(prr, 'prr')" etc.
To run the resulting code, run pint with the prr output produced by pcom as input for the file 'prd', and input for the compiled Pascal program on standard input.
I have compiled it with Free Pascal (on https://ideone.com/), but failed too.
Free Pascal Compiler version 2.6.4+dfsg-4 [2014/10/14] for i386
Copyright (c) 1993-2014 by Florian Klaempfl and others
Target OS: Linux for i386
Compiling pcom.p
pcom.p(1,3) Warning: Unsupported switch "$L"
pcom.p(88,23) Fatal: Syntax error, ":" expected but ")" found
Fatal: Compilation aborted
Error: /usr/bin/ppc386 returned an error exitcode (normal if you did not specify a source file to be compiled)
I don't know how to compile this source code in Windows machine, because I know Pascal language only.
Can I compile it with Turbo Pascal (without any requirement) on Windows XP? Can you remove some part of script for Pascal compiling only?
Free Pascal's Florian has been working getting Scott Moore's P5 compiler (which is a P4 compiler accepting a larger subset of Pascal) to work with FPC's ISO mode for old sources. However it will work (mostly) only in development versions (including the upcoming "stable" branch 3.0.x).
I tried last summer and it compiled and generally worked with FPC 3.x and the -Miso parameter (to select ISO style dialects). IIRC the last thing fixed was ISO style parameter transfer.
I quickly tried the referenced P4 compiler version and it seems to stumble on a few spots with "comment this" comments related to switching back and fro from ISO Mode. If I comment those files, pint compiles. (and then you could run the original bytecode if necessary)
pcom then still stumbles on taking the ord() of a pointer, which is obviously not very portable either, but unfortunately with 20+ occurrences that have to be replaced with ord(ptrint()).
pcom still doesn't compile then, FPC doesn't like passing union fields to VAR parameters. Working around that with a variable and the source compiles, 15 minutes total.
The fixed sourcecode with extra mode statements is at http://www.stack.nl/~marcov/files/p4fixed.zip but requires (as yet unreleased) FPC 3.0 or newer.
The resulting EXE binary can compile the original pcom source to bootstrap itself to bytecode.
You want to get an ISO 7185 compliant compiler to compile that. It is true that Pascal-P4 (the proper name) was written prior to the ISO 7185 standard. However, the adaption to the standard is generally less of a change set than adaption to a dielect.
You will find that work already done and documented at:
http://sourceforge.net/projects/pascalp4/
It specifies use of GPC. However, as Marco said, it is possible with more work to adapt to FPC, and I believe the FPC folks are improving the ISO 7185 capability of their compiler.
Having said that, I'm not sure why Pascal-P4 would be an interesting target. Pascal-P4 was a subset compiler, meaning an incomplete implementation of Pascal. You will find a complete implementation as Pascal-P5:
http://sourceforge.net/projects/pascalp5/
And I believe it has less portability issues as well.
Good luck.
--disable-hosted-libstdcxx
only build freestanding C++ runtime support
from the <gcc>/libstdc++-v3/configure --help .
What is this freestanding mode and what are the limits and the benefits ?
For the very little that I know about it looks like it's equivalent to some static linkage of the libstdc++ but then what is the point of this "mode" if you can just build your *.a library ? It doesn't sound like a good explanation.
"freestanding" is a minimal configuration for a c++ program, as opposed to "hosted" (full standard library support making use of advanced platform OS features). In theory, "freestanding" c++ program can be made to run on bare iron.
In "freestanding" mode only the following headers can be safely used:
cstdarg
cstddef
cstdlib
exception
limits
new
exception
typeinfo
With optional:
cxxabi.h.
And C++11 ones:
initializer_list
type_traits
Applications must link to "libsupc++.a" library for limited runtime features support.
http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dynamic_or_shared.html
This is supposed to conform to section 17.6.1.3 of the c++ standard (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf)
Freestanding is used if you are making an operating system, or if you are using an operating system that may not support the standard libraries.
This question was emerged from this question.
The problem is that there is a NVidia driver for Linux, compiled wth GCC 4.5. The kernel is compiled with GCC 4.6. Well, the stuff doesn't work because of the version number difference between GCCs. (the installer says the driver won't work - for details please visit the link above)
Could one disguise a binary compiled with GCC 4.5 to a binary compiled with GCC 4.6? If it is possible, under what circumstances would it work well?
Your problem is called ABI: Application Binary Interface. This is a set of rules (among others) how functions in a piece of code get their arguments (ordering, padding of types on the stack), naming of the function so the linker can resolve symbols and padding/alignment of fields in structures.
GCC tries to keep the ABI stable between compiler versions but that's not always possible.
For example, GCC 4.4 fixed a bug in packed bit-fields which means that old/new code can't read structures using this feature properly anymore. If you would mix versions before and after 4.4, data corruption would occur without any crashes.
There is no indication in the 4.6 release notes that the ABI was changed but that's something which the Linux kernel can't know - it just reads the compiler version used to compile the code and if the first two numbers change, it assumes that running the code isn't safe.
There are two solutions:
You can compile the Nvidia driver with the same compiler as the kernel. This is strongly recommended
You can patch the version string in the binary. This will trick the kernel into loading the module but at the risk of causing data corruption to internal data structures.