Problem:
I need to install Primer3, a widely used bio tool that finds allows one to design primers.
Attempts at resolution:
I have attempted to follow their instructions for a Windows installation to no avail as it does not seem provide enough information. I not a experienced programmer by any means. So far I've also referenced this stack overflow post about a similar issue and tried to follow the suggested answer. I also briefly looked at a thread in their github repository, though I can't really understand what they are saying in it. Nothing seems to work so far as the output I get from my command terminal (the mingw32 version) is this:
C:\Users\mqian\Desktop\CGIProject\primer3-2.4.0\primer3-2.4.0\test>mingw32-make
TESTOPTS=--windows
cd ..\src & mingw32-make
mingw32-make[1]: Entering directory 'C:/Users/mqian/Desktop/CGIProject/primer3-2
.4.0/primer3-2.4.0/src'
g++ -c -g -Wall -D__USE_FIXED_PROTOTYPES__ -O2 masker.c
masker.c:8:22: fatal error: sys/mman.h: No such file or directory
compilation terminated.
Makefile:226: recipe for target 'masker.o' failed
mingw32-make[1]: *** [masker.o] Error 1
mingw32-make[1]: Leaving directory 'C:/Users/mqian/Desktop/CGIProject/primer3-2.
4.0/primer3-2.4.0/src'
Makefile:94: recipe for target 'makeexes' failed
mingw32-make: *** [makeexes] Error 2
and if I just try to run a make in the src folder:
C:\Users\mqian\Desktop\CGIProject\primer3-2.4.0\primer3-2.4.0\src>mingw32-make
g++ -c -g -Wall -D__USE_FIXED_PROTOTYPES__ -O2 masker.c
masker.c:8:22: fatal error: sys/mman.h: No such file or directory
compilation terminated.
Makefile:226: recipe for target 'masker.o' failed
mingw32-make: *** [masker.o] Error 1
Is it something that I missing in terms of a software or package needed? Is their makefile bugged? Any help would be appreciated.
P.S. here is a link to their download site on sourceforge. I am using version 2.4.0.
I was able to build it like this on Windows (replace /usr/local with the path where you want to install):
Build mman-win32 from https://github.com/witwall/mman-win32/releases under MSYS2 using:
./configure --prefix=/usr/local --cc=gcc --enable-static --enable-shared &&
make &&
mkdir -p /usr/local/include/mman-win32/sys /usr/local/lib &&
cp -f *.h /usr/local/include/mman-win32/sys/ &&
cp -f *.a /usr/local/lib/ &&
echo Success
Then build primer3 from https://github.com/primer3-org/primer3/releases:
mv src/masker.c src/masker.c.bak
cat > src/masker.c << EOF
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define GETLINE_BUFLEN 128
static ssize_t getline(char** lineptr, size_t* n, FILE* stream)
{
char* bufptr;
char* p;
ssize_t size;
int c;
if (!lineptr || !n || !stream)
return -1;
bufptr = *lineptr;
size = *n;
c = fgetc(stream);
if (c == EOF)
return -1;
if (!bufptr) {
if ((bufptr = (char*)malloc(GETLINE_BUFLEN)) == NULL)
return -1;
size = GETLINE_BUFLEN;
}
p = bufptr;
while (c != EOF) {
if ((p - bufptr) > (size - 1)) {
size = size + GETLINE_BUFLEN;
if ((bufptr = (char*)realloc(bufptr, size)) == NULL)
return -1;
}
*p++ = c;
if (c == '\n') {
break;
}
c = fgetc(stream);
}
*p++ = 0;
*lineptr = bufptr;
*n = size;
return p - bufptr - 1;
}
EOF
cat src/masker.c.bak >> src/masker.c
make -Csrc install PREFIX=/usr/local CC_OPTS="-I/usr/local/include/mman-win32" LDLIBS="-Wl,--as-needed -lmman" &&
echo Success
I am trying to pass a "define variable called DEBUG" at compile time for a kernel module.
i.e provide the same functionality as DEBUG does below, but in a Makefile for a kernel module.
gcc -o foo -DDEBUG=1 foo.c
Can anyone give me a hint on how this can be achieved?
The Makefile:
# name of the module to be built
TARGET ?= test_module
# How to pass this during compile time? (-D$(DEBUG) or something similar)
DEBUG ?= 1
#define sources
SRCS := src/hello.c
#extract required object files
OBJ_SRCS := $(SRCS:.c=.o)
#define path to include directory containing header files
INCLUDE_DIRS = -I$(src)/includes
ccflags-y := $(INCLUDE_DIRS)
#define the name of the module and the source files
obj-m += $(TARGET).o
$(TARGET)-y := $(OBJ_SRCS)
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
#echo "insert module:\n\t sudo insmod $(TARGET).ko"
#echo "remove module:\n\t sudo rmmod $(TARGET)"
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
I am using the module from link (with a small change in the init function, see the #if #endif statement)
hello.c:
#include <linux/module.h> // included for all kernel modules
#include <linux/kernel.h> // included for KERN_INFO
#include <linux/init.h> // included for __init and __exit macros
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Lakshmanan");
MODULE_DESCRIPTION("A Simple Hello World module");
static int __init hello_init(void)
{
#if (DEBUG == 1)
printk(KERN_INFO "DEBUG = 1\n")
#endif
printk(KERN_INFO "Hello world!\n");
return 0; // Non-zero return means that the module couldn't be loaded.
}
static void __exit hello_cleanup(void)
{
printk(KERN_INFO "Cleaning up module.\n");
}
module_init(hello_init);
module_exit(hello_cleanup);
I would like to see that dmesg poduces the following after
sudo insmod test_module.ko
DEBUG = 1
Hello world!
Solution:
ccflags-y := -DDEBUG=$(DEBUG)
Made the code below execute as intended
#if (DEBUG == 1)
printk(KERN_INFO "DEBUG = 1\n")
#endif
ccflags-y := -DDEBUG=$(DEBUG)
Made the code below execute as intended
#if (DEBUG == 1)
printk(KERN_INFO "DEBUG = 1\n")
#endif
I have compiled this code:
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/genhd.h> // declaration of printk_all_partitions()
MODULE_LICENSE("GPL");
int __init start (void) {
printk ("evaluating the module ") ;
printk_all_partitions();
printk (" module inserted .. ");
return 0 ;
}
void __exit x(void) {
printk ("module unloaded ..");
}
module_init(start);
module_exit (x);
MODULE_LICENSE("GPL");
makefile is:
EXTRA_CFLAGS += -Wall
obj-m += printk_all_partitions.o
all :
make -C /lib/modules/$(shell uname -r )/build M=$(PWD) modules
clean :
make -C /lib/modules/$(shell uname -r )/build M=$(PWD) clean
when I run make I get
WARNING: "printk_all_partitions" [/root/c++/modulez/multiple_source_files/printk_plm/printk_all_partitions.ko] undefined!
egrep -w 'printk|printk_all_partitions' /proc/kallsyms :
ffffffff8162f135 T printk
ffffffff81ac7b46 T printk_all_partitions
Now the only difference between printk and printk_all_partitions is that printk_all_partitions does not exist in the Module.symvers
and printk is:
0x27e1a049 printk vmlinux EXPORT_SYMBOL
By the time i finished the writing I found out that a function must be EXPORT_SYMBOL-ed too in order for it to work
but if (somehow) Modules.symvers was deleted , and the kernel sources were not available, both printk and printk_all_partitions are begin with a "T", what other way to know is one is exported or not?
Normally this line
obj-m += printk_all_partitions.o
is the name of the module you're trying to create. In this case you're naming your module the same as an existing symbol, is this deliberate?
In searching the site, I found two other similar (at first glance) questions by users 2253605
and 2135159. I also have tried two different versions of gcc. This started out as a hard to
track problem in an application to keep various forms of data in sync on different media. I
eventually boiled it down to a few lines of code that illustrate the problem.
This one is very defined and puzzling. I have not been able to find a case where my system opens
a file, and returns a non-zero file descriptor. It sometimes does really open the specified file
and allows a subsequent read() to occur without error. But by the third open() the
subsequent read() fails, specifying an invalid argument, which can only be a zero value file
descriptor.
The code below tries to open 5 different files, 4 files exist and one that does not exist.
The first 4 opens all return a file descriptor value of zero (stdin).
stdin is not closed, a read() before the first open() or after any one of these open() calls,
will hang until enter is pressed.
Even if stdin were closed, zero should only be returned for the first open(). The
file descriptors are being set and when the open() for the non-existent file is attempted,
it returns an error.
I can't believe that gcc can't open a file. I think I have some kind of O/S-compiler configuration
issue (lib) or maybe I can't see the forest for the trees.
This is on ubuntu 12.04 LTS 64 bit and 64 bit gcc-4.6 also on gcc-4.7 . The flash drive is
formatted ext4. x86_64 intel processor. The installation commands used for gccc-4.7 on 2/10/16
are also shown below. Both gcc-4.6 and gcc-4.7 give identical results. The makefile
is at the end.
Anybody know what's happening here?
The terminal output is shown below the code.
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h
#include <errno.h>
int main()
{
long ret_val;
char cpy_buf[4096];
char s_ary[20][80] =
{
"/media/FLASH16GB_2/Test_dir/t_dir/dm1", //0 exists
"/media/FLASH16GB_2/Test_dir/t_dir/dm2", //1 exists
"/media/FLASH16GB_2/Test_dir/t_dir/dm3", //2 exists
"/media/FLASH16GB_2/Test_dir/t_dir/dm4", //3 exists
"/media/FLASH16GB_2/Test_dir/t_dir/dm5", //4 does not exist
};
char *s1;
long s_fh_1, s_fh_2, s_fh_3, s_fh_4, s_fh_5;
s_fh_1 = 10000;
s1 = &s_ary[0][0];
if (s_fh_1 = open( s1 , O_RDONLY) < 0) // &s_ary[0][0]
{
printf("Error opening source file, name=%s, line# = %i, errno = %i \n",&s_ary[0][0], __LINE__ , errno);
return -1;
}
if (s_fh_2 = open( &s_ary[1][0], O_RDONLY) < 0)
{
printf("Error opening source file, name=%s, line# = %i, errno = %i \n",&s_ary[1][0], __LINE__ , errno);
return -1;
}
if (s_fh_3 = open( &s_ary[2][0], O_RDONLY,0) < 0)
{
printf("Error opening source file, name=%s, line# = %i, errno = %i \n",&s_ary[2][0], __LINE__ , errno);
return -1;
}
if (s_fh_4 = open( &s_ary[3][0], O_RDONLY,0) < 0)
{
printf("Error opening source file, name=%s, line# = %i, errno = %i \n",&s_ary[3][0], __LINE__ , errno);
return -1;
}
printf("s_fh_1 = %li, s_fh_2 = %li, s_fh_3 = %li, s_fh_4 = %li \n", s_fh_1, s_fh_2, s_fh_3, s_fh_4);
if (s_fh_5 = open( &s_ary[4][0], O_RDONLY,0) < 0)
{
printf("Error opening source file, name=%s, line# = %i, errno = %i \n",&s_ary[4][0], __LINE__ , errno);
return -1;
}
return 0;
}
terminal output:
$ make
gcc -g -c -std=iso9899:1999 -o obj/bug_tst_sync_m.o bug_tst_sync_m.c -I../include
gcc -o bug_tst_sync_m obj/bug_tst_sync_m.o -I../include -L /usr/lib64/X11 -lX11 -lm
$ ./bug_tst_sync_m
s_fh_1 = 0, s_fh_2 = 0, s_fh_3 = 0, s_fh_4 = 0
Error opening source file, name=/media/FLASH16GB_2/Test_dir/t_dir/dm5, line# = 88, errno = 2
$
$
gcc-4.7 installation commands used on 2_10_16.
update-alternatives --display gcc
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install gcc-4.7
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.7 60
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 40
sudo update-alternatives --config gcc
makefile
### where to look for include files ( locally and globally ? -I /usr/include/X11)
IDIR =../include
### compiler to runand generate debugging info (no -g for production release code)
CC=gcc -g
### list of dependencies
CFLAGS=-I$(IDIR)
### where to put object modules
ODIR=obj
### where to look for local library files locally (or write?)
LDIR = -L /usr/lib64/X11 -lX11
### libraries to include m=-lm includes the math libarary, math lib = -lm
LIBS=-lm
### list of all dependency files (.h files)
_DEPS = queues.h InterlockedExchange.h
DEPS = $(patsubst %,$(IDIR)/%,$(_DEPS))
### list of all object files
_OBJ = bug_tst_sync_m.o
OBJ = $(patsubst %,$(ODIR)/%,$(_OBJ))
### compiles object modules and produces debug info
$(ODIR)/%.o: %.c $(DEPS)
$(CC) -c -std=iso9899:1999 -o $# $< $(CFLAGS)
### left side of colon is executable name
### this line links objects and creates the executable
bug_tst_sync_m: $(OBJ)
gcc -o $# $^ $(CFLAGS) $(LDIR) $(LIBS)
### this gets run if you type "make clean". it deletes source backup and object files.
### run this then next make does everything. Without this you get situations that
.PHONY: clean
clean:
rm -f $(ODIR)/*.o *~ core $(INCDIR)/*~
Your problem is operator precedence, < binds harder than =;
if ( s_fh_1 = open(s1 , O_RDONLY) < 0 )
becomes
if ( s_fh_1 = ( open(s1 , O_RDONLY) < 0 ) )
which means, if open returns a number greater than or equal to zero, s_fh_1 will be 0.
I suspect that the manual is actually saying what I'm doing wrong, but I can't really see a solution; the problem occurs when the .c file and the .o file to be build are not in the same directory, and the .c file has an automatic dependency on a .h file which has to be generated on the fly. The problem can be probably be solved by manually setting dependencies between the .c and .h file, but I would like to avoid that.
I have the following directory structure:
weird/
Jamfile
b.c
src/
a.c
c.c
The src/a.c file is like this:
#include "src/a.h"
int main(int argc, char *argv[])
{
return 0;
}
The b.c file is like this:
#include "src/b.h"
int main(int argc, char *argv[])
{
return 0;
}
The src/c.c file is like this:
#include "c.h"
int main(int argc, char *argv[])
{
return 0;
}
The Jamfile is:
rule CreateHeader
{
Clean clean : $(1) ;
}
actions CreateHeader
{
echo "int x = 10;" > $(1)
}
Object a.o : src/a.c ;
Object b.o : b.c ;
Object c.o : src/c.c ;
CreateHeader src/a.h ;
CreateHeader src/b.h ;
CreateHeader src/c.h ;
The following command correctly creates b.o and src/b.h:
jam b.o
The following command creates src/a.h, but then GCC fails to create a.o; the reason is quite obviously that the #include in a.c mentions src/a.h while in fact should simply refer to a.h:
jam a.o
The following command fails completely, and does not even create c.h; the reason is probably that when Jam analyzes c.c it generates a dependency on c.h instead of src/c.h, and in the Jamfile there are no rules for generating c.h:
jam c.o
This command compiles properly if I explicitly ask to generate src/c.h before asking for c.o:
jam src/c.h
jam c.o
In my opinion the jam src/c.h should not be necessary. What's wrong here? Check the Jam manual for more information, particularly under the section Header File Scanning.
Added after I accepted the answer
I kept experimenting a little bit with the constructs suggested by the author of the accepted answer, and I'll post here the results. In this setting you can type:
jam app
And the application will be linked under bin/app. Unfortunately I had to use a UNIX path when setting LOCATE_TARGET, and my understanding is that this is not exactly a good practice.
Directory Structure:
project/
Jamfile
src/
main.c
gen/
bin/
obj/
File Jamfile:
SubDir TOP ;
rule CreateHeader
{
MakeLocate $(1) : $(LOCATE_SOURCE) ;
Clean clean : $(1) ;
}
actions CreateHeader
{
BUILD_DATE=`date`
echo "char build_date[] = \"$BUILD_DATE\";" > $(1)
}
SEARCH_SOURCE = src ;
LOCATE_TARGET = bin/obj ;
SubDirHdrs gen ;
Object main.o : main.c ;
LOCATE_TARGET = bin ;
MainFromObjects app : main.o ;
LOCATE_SOURCE = gen ;
CreateHeader info.h ;
File src/main.c
src/main.c
#include <stdio.h>
#include "info.h"
int main(int argc, char *argv[])
{
printf("Program built with Jam on %s.\n", build_date);
return 0;
}
Changing all #include directives to omit the path (i.e. '#include "a.h' etc.) and changing the Jamfile to the following will solve your issues:
SubDir TOP ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) src ] ;
LOCATE_SOURCE = [ FDirName $(SUBDIR) src ] ;
rule CreateHeader
{
MakeLocate $(1) : $(LOCATE_SOURCE) ;
Clean clean : $(1) ;
}
actions CreateHeader
{
echo "int x = 10;" > $(1)
}
Object a.o : a.c ;
Object b.o : b.c ;
Object c.o : c.c ;
CreateHeader a.h ;
CreateHeader b.h ;
CreateHeader c.h ;
Here're the details:
SubDir should always be invoked in a Jamfile. It sets up several helpful (and in some cases necessary) variables, including SUBDIR, SEARCH_SOURCE, and LOCATE_SOURCE which are used here.
Adding the "src" subdirectory to SEARCH_SOURCE allows you to omit the "src/" part for the source files in the Object rule invocations. SEARCH_SOURCE is also automatically added to the include directories, which is why the #include directories can be shortened.
LOCATE_SOURCE is the directory where generated source files (e.g. generated yacc sources and headers) are placed. For sake of consistency CreateHeader uses this variable. Note that this allows (and requires) you to omit the "src/" part in the CreateHeader invocations.
So the general thrust of these changes is to omit the "src/" part from target names used in the Jamfile. It is generally recommended to omit directory components in Jamfiles (and use grist for disambiguation instead). It is important to note that the way Jam works targets with the names "src/a.h" and "a.h" are different targets, even if the former is considered to be located in "." and the latter in "./src" (e.g. by means of the on-target SEARCH or LOCATE variables). With the files you gave Jam's header scanning results in the following include dependencies (those are target names):
src/a.c : src/a.h
b.c : src/b.h
src/c.c : c.h
This makes obvious why jamming "c.o" fails: The target "c.h" is unknown, since the target name of the header you declare to be generated is "src/c.h". Hence jam ignores the include dependency. The reason for the failing "jam a.o" is the one you suspected.
The change I suggest requires adjusting the #include directives in the source files, which may not be desirable/possible in your actual use case. The situation would still be salvageable. E.g. you can change the Jamfile as suggested, but extend the CreateHeader rule:
rule CreateHeader
{
MakeLocate $(1) : $(LOCATE_SOURCE) ;
Clean clean : $(1) ;
Depends src/$(1) : $(1) ;
NotFile src/$(1) ;
}
This is obviously a bit of a hack. It defines the targets "src/a.h" and friends as pseudo targets, each depending on the corresponding actual target ("a.h" etc.). This way Jam's header scanning will result in a known target regardless of whether it has the "src/" prefix or not.
The less hacky solution is to explicitly declare the include relations, though:
Includes a.c : a.h ;
Includes b.c : b.h ;