How can I add a prefix to all macros defined in config.h by Autotool? For example, I want #define MYNAMESPACE_HAVE_STRING_H 1 instead of #define HAVE_STRING_H 1. I have found a post saying that AX_PREFIX_CONFIG_H can help but my system doesn't support this macro...
AC_CONFIG_FILES([Makefile])
AC_CONFIG_HEADERS([include/config.h])
AX_* macros come from Autoconf Archive, in particular the one you're referring to is described in http://www.gnu.org/software/autoconf-archive/ax_prefix_config_h.html.
That is probably the best way to achieve it, just copy the latest m4 file for that macro in your project and let it be found by autoreconf. You can refer to my write-up in Autotools Mythbuster for further details on using external macro files.
Related
I have a Fortran code which has been made to work on CPUs, but I need to accelerate it using GPUs and I chose to do that with OpenACC.
This code uses FFTW libraries when compiled with gfortran. However, as you may know, these libraries cannot be used with nvfortran. So, I have to go with cufft libraries.
Therefore, I used this conversion giude. The problem is, fftw allows users to build a Fortran module with iso_c_binding including the file fftw.f, while cufft does not have this kind of feature and you need to include the cufft.h header.
When compiling with nvfortran (I use -cpp, -Mfree, -lcufft and -l cufftw flags, checked the include and lib directories given to -I and -L flags) I get many errors:
The paths in all the #include inside the cufft.h file are wrong and I had to change them manually
All the comments ("//") in the header files are seen as errors (had to remove them manually)
“Label field of continuation line is not blank” errors everywhere in header files, starting from line 2 (in lines 1 I solved that giving 7 spaces - but didn’t I use -Mfree for that?)
Please help me, I don’t think that the right way to do so is to change files manually…
Thanks in advance for helping
You cannot include headers for the C programming language in Fortran source code. Instead use the Fortran interfaces to any libraries you need (provided such interfaces exist).
We ship a cuFFT interface module with the compilers. You should just be able to add "use cufft".
Full documentation can be found at: https://docs.nvidia.com/hpc-sdk/compilers/fortran-cuda-interfaces/index.html#cf-fft-runtime
Example codes are shipped with the NVHPC SDK which can be found in the "<INSTALL_DIR>/Linux_x86_64/<RELEASE>/examples/CUDA-Libraries/cuFFT/"" directory
Context:
I'm trying to automate some of the more mundane tasks in embedded development with Keil. The end result I'm aiming for is that clicking build in a Keil project will run a pre-build step that runs all the code through Uncrustify (a source code beautifier) to ensure it conforms to the company style-guide, and a post-build step which then runs the code through pc-lint (a static code analyser) to highlight any potentially unsafe code that it might find. I've written a PC utility that searches through the .uvproj file for the #define macros, the include paths and the file-paths all of which are needed for both tools and then modifies the pre and post-build user commands to call up my batch files which will manage both steps. The uncrustify part is working fine and the lint part is producing some sensible messages, but the signal-to-noise ratio isn't that great.
My problem:
Lint keeps on producing messages that seem to relate to macros that the Keil compiler is aware of, but that Lint isn't. I'm trying to find a way to plug that gap. I found a table of predefined macros documented on the Keil website, which seems like a good start, but rather than manually copying them into a static .lnt file, I'd like to find a way of grabbing the up-to-date values at the time the project gets built. This way, the "__ARMCC_VERSION" macro, for instance, would be updated whenever the developer updates his/her Keil compiler, rather than being stuck at a point in time whenever I manually copied it.
I'd love it if someone can answer my question directly, but I'd be equally pleased if someone has a viable suggestion for a more straightforward alternative approach I could try instead. Many thanks!
I am assuming you're using the Keil ARM Compiler.
From the Compiler User Guide:
To list macros that are defined on the command line, predefined by the compiler, and found in header and source files, use --list_macros with a non-empty source file.
To list only macros predefined by the compiler and specified on the command line, use --list_macros with an empty source file.
EDIT:
It looks like your SDK also adds a few macros.
From the µVision User's Guide:
The following control strings are added, depending on the use of MDK:
__UVISION_VERSION:
Major and minor version of µVision. For example: -D__UVISION_VERSION="520".
RTE:
Set when RTE is in use. For example: -D_RTE_.
__RTX:
Set when RTX Kernel has been selected in Options for Target - Target - Operation System. Not set when using RTE. For example: -D__RTX.
__MICORLIB:
Set when Use MicroLIB has been enabled in Options for Target - Target. For example: -D__MICROLIB.
__EVAL:
µVision runs in evaluation mode. License MDK-Lite. For example: -D__EVAL.
device header name:
Device header name.
We have a app inside which we have the mac executable. When we try to execute strings app_executable | grep User we get a particular file name with the full path as the output.
This should not happen as it is vulnerable and also it tells the developer's name and the folder structure details.
Kindly let me know how to avoid this.
The front end code is written in objective c.
The reason for this is that we use NSAssert() in our code which will lead to having the strings present in your executable which might disclose unwanted information about the project. To avoid this we can have NS_BLOCK_ASSERTIONS in the Project settings under preprocessoor macros for Release mode which will fix this or else we need to make sure the NSAssert is absolutely required if not, we can remove it.
Preprocessor Macros
Release - NS_BLOCK_ASSERTIONS
I know there are a lot of questions on this topic, and I've looked through a fair number of them. However I am still having problems.
I started writing a test program for a prototype PCB, and now that it's grown to nearly 1000 lines I'm trying to break it up into libraries that I can use for particular functions.
I thought this would be very simple. Make .c and .h files for each library that I need. I.e. I would have OLED.h and OLED.c for functions that control an OLED display. Copy the appropriate functions/definitions into each file. Then copy these files into the solution in Atmel Studio. I put them into the src folder under the project name.
However, this doesn't work! I get an exceedingly long list of errors. All of the things that are defined in the .h file are apparently undefined as far as the compiler is concerned. I also get many error messages of the type "unknown type name int16_t/uint16_t/uint8_t/etc..." That part is really baffling to me. Why should it matter that functions are in an external library, now the compiler doesn't understand what those data types mean?
So, this is probably a stupid problem to have. I don't want Atmel Studio to control my libraries by wrapping them up in some "library project" or somethig, I want to put them in a folder of my choosing and add them when I need them. I've searched for answers to this problem and I find long tutorials about changing the compiler settings for the project, the linker settings, etc... I tried this tutorial and still no dice: http://www.engblaze.com/tutorial-using-avr-studio-5-with-arduino-projects/#setup
I also can't find a way to add something by right clicking the project and clicking "Add." It wants me to find .a files. The "Add Library" dialog box in Atmel Studio is awful, it seems.
Surely it can't be that convoluted to just add a library to an existing project and have it function normally?! I've used PICs in the past and coming to Atmel I've found horrible documentation and a weird super-slick super-fly whizz bang interface that can't leave well enough alone and obfuscates simple function. What can I do to add these libraries?
UPDATE: Seemed to answer my own question. Turns out I needed to include all of the libraries to recognize data types and whatnot into the .c file. I somehow assumed this only had to be done in the main file but obviously I was mistaken. Adding asf.h seems to work well as it includes all of the MCU specific port definitions/names and all of that. All good for now!
Adding library files to a solution should be simple. Go to the Solution Explorer, right-click on your solution, and go to "Add->Existing Item". If you want to add a pre-existing library and keep it in a separate folder from your solution, click the arrow next to "Add" and choose "Add as link". That saves many headaches due to having a duplicate copy of your library in your solution folder, and files not staying up-to-date.
You are right in saying that you need to include the necessary header files in the .c files where they are used.
The compiler compiles each C file separately, and then links them together at the end, so you got the error unknown typename int_* because the compiler had not seen the relevant header in the context of compiling that C file.
You also seem to be in some confusion as to the difference between definition and declaration.
A function is:
Declared in the header file. This means there is a function prototype, e.g. int some_func(char some_var); which tells the compiler that the function exists, but does not tell it what it is. This is necessary because the compiler only looks at one C file at a time, so needs to be told that other functions exist.
Defined in the C file.This is the actual function body, i.e. int some_func(char some_var) { do_stuff(some_var); }. After compilation of each individual C file in isolation, the linker is called to put all the pieces together and give you your final binary, which you flash to the device.
A function can be (and must be) defined only once, but may be declared many times - even in the same file, so long as the declarations are not conflicting.
I'm having trouble understanding if/how to share code among several Fortran projects without building libraries or duplicating source code.
I am using Eclipse/Photran with the Intel compiler (ifort) on a linux system, but I believe I'm having a bigger conceptual problem with modules than with the specific tools.
Here's a simple example: In ~/workspace/cow I have a source directory (src) containing cow.f90 (the PROGRAM) and two modules m_graze and m_moo in m_graze.f90 and m_moo.f90, respectively. This project builds and links properly to create the executable 'cow'. The executable and modules (m_graze.mod and m_moo.mod) are stored in ~/workspace/cow/Debug and object files are stored under ~/workspace/cow/Debug/src
Later, I create ~/workplace/sheep and have src/sheep.f90 as the program and src/m_baa.f90 as the module m_baa. I want to 'use m_graze, only: ruminate' in sheep.f90 to get access to the ruminate() subroutine. I could just copy m_graze.f90 but that could lead to code getting out of sync and doesn't take into account any dependencies m_graze might have. For these reasons, I'd rather leave m_graze in the cow project and compile and link sheep.f90 against it.
If I try to compile the sheep project, I'll get an error like:
error #7002: Error in opening the compiled module file. Check INCLUDE paths. [M_GRAZE]
Under Properties:Project References for sheep, I can select the cow project. Under Properties:Fortran Build:Settings:Intel Compiler:Preprocessor I can add ~/workspace/cow/Debug (location of the module files) to the list of include directories so the compiler now finds the cow modules and compiles sheep.f90. However the linker dies with something like:
Building target: sheep
Invoking: Intel(R) Fortran Linker
ifort -L/home/me/workspace/cow/Debug -o "sheep" ./src/sheep.o
./src/sheep.o: In function `sheep':
/home/me/workspace/sheep/src/sheep.f90:11: undefined reference to `m_graze_mp_ruminate_'
This would normally be solved by adding libraries and library paths to the linker settings except there are no appropriate libraries to link to (this is Fortran, not C.)
The cow project was perfectly capable of compiling and linking together cow.f90, m_graze.f90 and m_moo.f90 into an executable. Yet while the sheep project can compile sheep.f90 and m_baa.f90 and can find the module m_graze.mod, it can't seem to find the symbols for m_graze even though all the requisite information is present on the system for it to do so.
It would seem to be an easy matter of configuration to get the linker portion of ifort to find the missing pieces and put them together but I have no idea what magic words need to be entered where in the Photran UI to make this happen.
I confess an utter lack of interest and competence in C and the C build process and I'd rather avoid the diversion of creating libraries (.a or .so) unless that's the only way to make this work.
Ultimately, I'm looking for a pure Fortran solution to this problem so I can keep a single copy of the source code and don't have to manually maintain a pile of custom Makefiles.
So can this be done?
Apologies if this has already been documented somewhere; Google is only showing me simple build examples, how to create modules, and how to link with existing libraries. There don't seem to be (m)any examples of code reuse with modules that don't involve duplicating source code.
Edit
As respondents have pointed out, the .mod files are necessary but not sufficient; either object code (in the form of m_graze.o) or static or shared libraries must be specified during the linking phase. The .mod files describe the interface to the object code/library but both are necessary to build the final executable.
For an oversimplified toy problem such as this, that's sufficient to answer the question as posed.
In a larger project with more complex dependencies (in my case, 80+KLOC of F90 linking to the MKL version of LAPACK95), the IDE or toolchain may lack sufficient automatic or user-interface facilities to make sharing a single canonical set of source files a viable strategy. The choice seems to be between risking duplicate source files getting out of sync, giving up many of the benefits of an IDE (i.e. avoiding manual creation of make/CMake/SCons files), or, in all likelihood, both. While a revision control system and good code organization can help, it's clear that sharing a single canonical set of source files among projects is far from easy given the current state of Eclipse.
Some background which I suspect you already know: Typically (including ifort) compiling the source code for a Fortran module results in two outputs - a "mod" file that contains a description of the Fortran entities that the module defines that the compiler needs to find whenever it sees a USE statement for the module, and object code for the linker that implements the procedures and variable storage, etc., that the module defines.
Your first error (the one you solved) is because the compiler couldn't find the mod file.
The second error is because the linker hasn't been told about the object code that implements the stuff that was in the source file with the module. I'm not an Eclipse user by any means, but a brute force way of specifying that is just to add the object file (xxxxx/Debug/m_graze.o) as an additional linker option (Fortran Build > Settings, under Intel Fortran Linker > Command Line). (Other tool chains have explicit "additional object file" properties for their link stage - there may well be a better way of doing this for the Intel chain.)
For more involved examples you would typically create a library out of the shared code. That's not really C specific, the only Fortran aspect is that the libraries archive of object code needs to be provided alongside the mod files that the Fortran compiler generates.
Yes the object code must be provided. E.g., when you install libnetcdf-dev in Debian (apt-get install libnetcdf-dev), there is a /usr/include/netcdf.mod file that is included.
You can now use all netcdf routines in your Fortran code. E.g.,
program main
use netcdf
...
end
but you'll have link to the netcdf shared (or static) library, i.e.,
gfortran -I/usr/include/ main.f90 -lnetcdff
However, as user MSB mentioned the mod file can only be used by gfortran that comes with the distribution (apt-get install gfortran). If you want to use any other compiler (even a different version that you may have installed yourself) then you'll have to build netcdf yourself using that particular compiler.
So creating a library is not a bad solution.