Installing PThread on linux for tophat - linux

Bowtie is a program which is needed for tophat. I need this program to map a few hundredmilion reads against a reference genome. Bowtie does the mapping part, this needs many CPU. In the manual of bowtie there is an option to do this multithreaded, but the library PThread needs to be installed.
I downloaded PThread from this website. Extracted this to my program folder, opened a shell and was standing in this directory. When entering the command 'make', I get this error and I don't know how to solve this.
if /bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I. -Wall -g -O2 -MT PThreadRun.lo -MD -MP -MF ".deps/PThreadRun.Tpo" -c -o PThreadRun.lo PThreadRun.cpp; \
then mv -f ".deps/PThreadRun.Tpo" ".deps/PThreadRun.Plo"; else rm -f ".deps/PThreadRun.Tpo"; exit 1; fi
g++ -DHAVE_CONFIG_H -I. -I. -I. -Wall -g -O2 -MT PThreadRun.lo -MD -MP -MF .deps/PThreadRun.Tpo -c PThreadRun.cpp -fPIC -DPIC -o .libs/PThreadRun.o
PThreadRun.cpp: In member function 'pthread_t PThreadRun::start()':
PThreadRun.cpp:28:38: error: 'redirectPthreadRun' was not declared in this scope
make: * [PThreadRun.lo] Error 1
make: Leaving directory `/install_dir'
make: * [all-recursive] Error 1
make: Leaving directory `/install_dir'
make: * [all] Error 2
Anyone knows how to solve this?

You need to run configure first. Per the installation instructions:
These are generic installation instructions.
The configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
those values to create aMakefile' in each directory of the package.
It may also create one or more .h' files containing system-dependent
definitions. Finally, it creates a shell scriptconfig.status' that
you can run in the future to recreate the current configuration, and a
file config.log' containing compiler output (useful mainly for
debuggingconfigure').
It can also use an optional file (typically called config.cache'
and enabled with--cache-file=config.cache' or simply `-C') that
saves the results of its tests to speed up reconfiguring. (Caching is
disabled by default to prevent problems with accidental use of stale
cache files.)
If you need to do unusual things to compile the package, please try
to figure out how configure' could check whether to do them, and mail
diffs or instructions to the address given in theREADME' so they can
be considered for the next release. If you are using the cache, and
at some point `config.cache' contains results you don't want to keep,
you may remove or edit it.
The file configure.ac' (orconfigure.in') is used to create
configure' by a program calledautoconf'. You only need
configure.ac' if you want to change it or regenerateconfigure'
using a newer version of `autoconf'.
The simplest way to compile this package is:
cd' to the directory containing the package's source code and type
./configure' to configure the package for your system. If you're
using csh' on an old version of System V, you might need to type
sh ./configure' instead to prevent csh' from trying to execute
configure' itself.
Running `configure' takes awhile. While running, it prints some
messages telling which features it is checking for.
Type `make' to compile the package.
Optionally, type `make check' to run any self-tests that come with
the package.
Type `make install' to install the programs and any data files and
documentation.
You can remove the program binaries and object files from the
source code directory by typing make clean'. To also remove the
files thatconfigure' created (so you can compile the package for
a different kind of computer), type make distclean'. There is
also amake maintainer-clean' target, but that is intended mainly
for the package's developers. If you use it, you may have to get
all sorts of other programs in order to regenerate files that came
with the distribution.

Related

How do I use a .lib with the "Visual C++ for linux" plugin?

I'm using the Visual C++ for Linux plugin. I can run a basic Hello world without problems. My actual project uses a .lib. It compiles fine but I get an error during linking (this is copied from Visual Studio's output pane):
ClCompile:
Starting remote build
Compiling sources:
Invoking g++
g++ -c -x c++ /home/devbox/projects/LinuxProgServ/LinuxProgServ/main.cpp -I /home/devbox/projects/LinuxProgServ/include/libuv -I /home/devbox/projects/LinuxProgServ/../include/lubuntu -I "/home/devbox/projects/LinuxProgServ/../include/lubuntu/x86_64-linux-gnu" -g2 -gdwarf-2 -o "/home/devbox/projects/LinuxProgServ/obj/x64/Debug/main.o" -Wall -Wswitch -W"no-deprecated-declarations" -W"empty-body" -Wconversion -W"return-type" -Wparentheses -W"no-format" -Wuninitialized -W"unreachable-code" -W"unused-function" -W"unused-value" -W"unused-variable" -O0 -fno-strict-aliasing -fno-omit-frame-pointer -fthreadsafe-statics -fexceptions -frtti -std=c++11
main.cpp
Done compiling '/home/devbox/projects/LinuxProgServ/LinuxProgServ/main.cpp'
Link:
Linking objects
Invoking ld
g++ -o "/home/devbox/projects/LinuxProgServ/bin/x64/Debug/LinuxProgServ.out" -Wl,--no-undefined /home/devbox/projects/LinuxProgServ/obj/x64/Debug/main.o -llibuv.lib
/usr/bin/ld: cannot find -llibuv.lib
collect2: error: ld returned 1 exit status
libuv.lib is specified in Project Properties>Linker>Input>Library Dependencies. I tried the following without success:
Copy the lib to /home/devbox/projects/lib and add that directory to
the linker command with -L, both using Visual Studio's additional
library folder field and directly in the Additional command line
options field. This results in the same final command.
Copy the lib to the output directory and set it to be copied
Add the local Windows path to Visual Studio's additional library folders
Add the linux path from #1 to Visual Studio's additional library folders
Try with another library
I made the same project but for Windows just to be sure and it works.
Am I missing something? Obviously I could just run the commands myself or use any variant of *make but that's not the point.
When you pass a library to g++ with -l, g++ helpfully prefixes the name you give with lib then looks for a file of that name with a .so or .a extension on the library search path. By convention, shared libraries (dlls) have the .so extension and static libraries the .a extension.
The route of least resistance would be to build your library with the .a extension, i.e. libuv.a then specify it to the VCLinux project library dependencies as uv. And specify the library search path with -L, as you do in your step 1.
Alternatively, you can put the full path of the library on the g++ link command line, without -l prefix, i.e. /home/devbox/projects/lib/libuv.lib and g++ will use it in the same way it uses other object files. Set via Linker/All Options/Additional Options.
Update: on reflection, this second approach won't work. Although g++ (gcc) will accept the library as an input when specified with its fully qualified path, the library must appear after the program object files for references to be resolved. Unfortunately there is no control over positioning of Additional Options in VCLinux which always puts them at the front of the parameter list on the g++ command line, i.e. before the object file(s). :(
And, at the risk of stating the obvious, the library must be built on Linux with g++ and be located on a path visible to g++ when linking your program.

Linker error in Codelite with MinGW-w64

I'm trying to use MinGW-W64 instead of MinGW in Codelite. When I compile simple "hello, world" project it's all right. But when I try to link some libraries, I get a strange linker error. Project with exactly same settings compiles by MinGW with any problems. There are build output for both variants:
MinGW GCC 4.8.1
`C:\Windows\system32\cmd.exe /C D:/apps/mingw/bin/mingw32-make.exe -j8 SHELL=cmd.exe -e -f Makefile
"----------Building project:[ code - Debug ]----------"
mingw32-make.exe[1]: Entering directory 'D:/Projects/codelite/code'
codelite-cc D:/apps/mingw/bin/g++.exe -c "D:/Projects/codelite/code/src/main.cpp" -Wfatal-errors -g -O0 -pedantic -W -std=c++11 -Wall -o ./Debug/src_main.cpp.o -I./inc/
D:/apps/mingw/bin/g++.exe -o bin/code #"code.txt" -L./lib/ -lopengl32
mingw32-make.exe[1]: Leaving directory 'D:/Projects/codelite/code'
====0 errors, 0 warnings====`
MinGW-W64 GCC 5.2.0
`C:\Windows\system32\cmd.exe /C D:/apps/mingw-w64/mingw32/bin/mingw32-make.exe -j8 SHELL=cmd.exe -e -f Makefile
"----------Building project:[ code - Debug ]----------"
mingw32-make.exe[1]: Entering directory 'D:/Projects/codelite/code'
codelite-cc D:/apps/mingw-w64/mingw32/bin/g++.exe -c "D:/Projects/codelite/code/src/main.cpp" -Wfatal-errors -g -O0 -pedantic -W -std=c++11 -Wall -o ./Debug/src_main.cpp.o -I./inc/
D:/apps/mingw-w64/mingw32/bin/g++.exe -o bin/code #"code.txt" -L./lib/ -lopengl32
g++.exe: error: #code.txt -L./lib/: No such file or directory
mingw32-make.exe[1]: *** [bin/code] Error 1
code.mk:78: recipe for target 'bin/code' failed
mingw32-make.exe[1]: Leaving directory 'D:/Projects/codelite/code'
mingw32-make.exe: *** [All] Error 2
Makefile:4: recipe for target 'All' failed
====1 errors, 0 warnings====`
This looks like a bug in your toolchain and not in CodeLite.
There is a space between the "#code.text" and -L./lib and for some reason g++ does not see it...
I put my money on the mingw32-make tool. You can tell CodeLite to use the mingw32-make.exe from the 4.8.1 version (which worked): settings->build settings->compilers->[YOUR COMPILER NAME]->Make
Another option is to disable the option that tells CodeLite to generate Makefile that passes the object list via file to the compiler:
Settings->Build Settings->compilers->[YOUR COMPILER NAME]->Advanced tab and uncheck the option: pass object list to the linker via file
Lately i too have found the similar problem. Later i was able to figure out the issue. We just to need to go to the project settings under change makefile generator default to codelite makefile generator i think that will work.

Eclipse-CDT on x86_64 system cannot link to shared library [duplicate]

This question already has answers here:
How to link to a shared library without lib* prefix in a different directory? [duplicate]
(2 answers)
Closed 2 years ago.
I compiled a few libraries using Eclipse-CDT on windows. However, when I tried to compile them under linux gcc keeps giving me the error /usr/bin/ld: cannot find -lrequestedLib. I'm using the exact same build settings between the two environments (namely I made sure to add the directories that contain the libraries i need to link to). I'm sure the system has read access rights to the files as well. I'm not sure what to make of this. Please help.
Edit: These are the commands that ecplise runs to build the library:
gcc -I/home/me/lib/ -O3 -Wall -c -fmessage-length=0 -olibToMake.o ../libToMake.c
gcc -L/home/me/lib/ -shared -olibToMake.so libToMake.o -lrequestedLib
Edit 2: The command that renders the error is the second of the two, resulting in the /usr/bin/ld: cannot find -lrequestedLib being output.
Edit 3: I've confirmed that requestedLib.so is a x86_64 binary.
If you don't want to pass -L command line options to gcc(1), be sure to add the path containing the libraries to /etc/ld.so.conf or /etc/ld.so.cond.d/<something>.
Once you've installed your libraries you also need to run ldconfig(8) by hand. (Most new users forget this step because typical package managers take care of this for you when installing new libraries.)
gcc -I/home/me/lib/ -O3 -Wall -c -fmessage-length=0 -olibToMake.o ../libToMake.c
gcc -L/home/me/lib/ -shared -olibToMake.so libToMake.o -lrequestedLib
When building 64-bit shared libraries on x86_64, the -fPIC flag is usually required, or you get a recompile with -fPIC error at shared library link time.
Since you didn't use -fPIC, yet your link succeeded, you are likely using (non-default) gcc that targets i*86 (that is, produces 32-bit output). You can confirm that by running file libToMake.so.
You didn't show that command that actually fails (the one that produces cannot find -lrequestedLib error). I am guessing that that command is using a different gcc (default one?), that targets x86_64. If it looks something like
gcc main.c -L/home/me/lib -lrequestedLib
that command will ignore /home/me/lib/librequestedLib.so (because you can't link together 32-bit and 64-bit code), and will continue searching for librequestedLib elsewhere. When it can't find a 64-bit version of librequestedLib, it will produce the error message you are gettiing.

Can't compile qc-usb driver? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Ubuntu 11.04 64-bit [Tried on SuSE 32-bit, and got same error], I have gcc, and can compile normal C programs.. and the linux headers in /usr/src/linux-headers-2.6*
I downlaoded this driver:
http://qce-ga.sourceforge.net/#download
downloaded, extracted, ran make all and this is the output
matt: /d/dl/qc-usb-0.6.6 $ make all
make -C "/lib/modules/2.6.38-8-generic/build" SUBDIRS="/home/matt/Desktop/dl/qc-usb-0.6.6" modules V=1 USER_OPT="-DHAVE_UTSRELEASE_H="
make[1]: Entering directory `/usr/src/linux-headers-2.6.38-8-generic'
test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \
echo; \
echo " ERROR: Kernel configuration is invalid."; \
echo " include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo " Run 'make oldconfig && make prepare' on kernel src to fix it."; \
echo; \
/bin/false)
mkdir -p /home/matt/Desktop/dl/qc-usb-0.6.6/.tmp_versions ; rm -f /home/matt/Desktop/dl/qc-usb-0.6.6/.tmp_versions/*
make -f scripts/Makefile.build obj=/home/matt/Desktop/dl/qc-usb-0.6.6
gcc -Wp,-MD,/home/matt/Desktop/dl/qc-usb-0.6.6/.qc-driver.o.d -nostdinc -isystem /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/include -I/usr/src/linux-headers-2.6.38-8-generic/arch/x86/include -Iinclude -include include/generated/autoconf.h -Iubuntu/include -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m64 -mtune=generic -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -fstack-protector -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wframe-larger-than=1024 -fno-omit-frame-pointer -fno-optimize-sibling-calls -pg -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -DNOKERNEL -DHAVE_UTSRELEASE_H= -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(qc_driver)" -D"KBUILD_MODNAME=KBUILD_STR(quickcam)" -c -o /home/matt/Desktop/dl/qc-usb-0.6.6/.tmp_qc-driver.o /home/matt/Desktop/dl/qc-usb-0.6.6/qc-driver.c
In file included from /home/matt/Desktop/dl/qc-usb-0.6.6/qc-driver.c:47:0:
/home/matt/Desktop/dl/qc-usb-0.6.6/quickcam.h:79:28: fatal error: linux/autoconf.h: No such file or directory
compilation terminated.
make[2]: *** [/home/matt/Desktop/dl/qc-usb-0.6.6/qc-driver.o] Error 1
make[1]: *** [_module_/home/matt/Desktop/dl/qc-usb-0.6.6] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.38-8-generic'
make: *** [quickcam.ko] Error 2
Note: I tried what this is suggesting I run [make oldconfig &&]. Here is a URL of the output: http://pastebin.com/ccnYn9uc
I googled a bit, and someone said to, in the kernel source, run make menuconfig and so I ran it but I have no clue what to change.. can you help me? thanks
You are trying to compile on 2.6.38, but include/linux/autoconf.h does not exist anymore since 2.6.33 (it was moved somewhere else in commit 264a26838056fc2d759f58bec2e720e01fcb1bdb). Besides, it should not need to be included by hand - the kernel build system does it automatically for you (see the -include in the gcc command line).
You do not need to run make menuconfig, and probably should not change anything using it - the kernel is already configured for your distribution, and changing it to something which does not match the running kernel can make the module not work correctly. Even make oldconfig should not be needed; what looks like a message saying to run make oldconfig is in fact code to detect if it is needed and print that message in that case (for some reason the driver you are trying to compile enabled some verbose mode which prints all commands before running them).
The problem you have is that the driver you are trying to compile is too old - the sourceforge release page shows it is from 2006, back when the latest kernel was still 2.6.18. The kernel internal API is not stable and changes frequently, so even if you fixed that error (probably simply removing the incorrect #include), it will probably still fail to compile due to several other changes. The drivers which come with the Linux kernel do not have that problem because it is the responsibility of the one who made the API change to fix all the drivers, but for drivers which are outside the Linux kernel tree, it is the driver author's responsibility to closely follow the kernel development and fix his driver whenever the API changed.
Your options are to find a newer driver (one which works in 2.6.38), or get someone who understands the Linux kernel to update your driver to 2.6.38. And to prevent it breaking in the future, it should be submitted to the Linux kernel.
And in fact, the kernel does seem to already have a driver for these devices. It is called gspca_stv06xx, and claims the three USB IDs the driver you were trying to compile claims - and many more.
One must wonder what did you Google. http://www.google.ca/search?sourceid=chrome&ie=UTF-8&q=%22fatal+error%3A+linux%2Fautoconf.h%3A+No+such+file+or+directory%22 very first result is a https://bbs.archlinux.org/viewtopic.php?id=103348 topic about a webcam(!) albeit on Arch it must be relevant. It's leading to http://aur.archlinux.org/packages.php?ID=9861 where you can find a tarball containing autoconf.patch. Read the topic and the linked Ubuntu topic it seems helpful.

How to prevent GCC from passing in default flags?

I am trying to cross-compile linux for an ARM architecture.
The host is an X86 machine running ubuntu-jaunty. I downloaded a cross-compile toolchain for ARM from http://ftp.arm.linux.org.uk/pub/armlinux/toolchain/. I downloaded the 2.95.3 version of the toolchain.
The problem I am having is that GCC is passing in some default flags by itself that is causing GCC to then output error:
/usr/local/arm/2.95.3/bin/arm-linux-gcc -specs=/home/feroze/wnr834m/marvell_WNR834M/gcc_specs -D__KERNEL__ -I/home/feroze/wnr834m/marvell_WNR834M/linux-88fxx81-1_1_3_gtk/include -Wall -Wstrict-prototypes -Wno-trigraphs -Os -fno-strict-aliasing -fno-common -DLED_DUAL_COLOR -DFOR_ROUTER -I/home/feroze/wnr834m/marvell_WNR834M/linux-88fxx81-1_1_3_gtk/arch/arm/mach-mv88fxx81/Soc/gpp/ -Uarm -fno-common -pipe -mapcs-32 -D__LINUX_ARM_ARCH__=5 -march=armv5 -mtune=arm9tdmi -mshort-load-bytes -msoft-float -Uarm -march=strongarm -DKBUILD_BASENAME=main -c -o init/main.o init/main.c
cc1: bad value (strongarm) for -march= switch
make[1]: *** [init/main.o] Error 1
make[1]: Leaving directory `/home/feroze/wnr834m/marvell_WNR834M/linux-88fxx81-1_1_3_gtk'
I checked the whole makefile, and could not find any place where LINUX_ARM_ARCH_5 and -march=armv5 are being defined. I am defining -march=strongarm in the makefile, but then it gets appended by theh ARMv5 defines.
So, I created a defs file from gcc, modified it to only have options for ARMv4, and then used it by specifying the -specs= option. However, that still doesnt solve the problem.
Can somemone help? How do I resolve this?
Thanks!
feroze
The -march flag is set in arch/ARM/Makefile, and depends on the machine you selected in your config file. If you don't want the armv5 flag, be sure to select the correct architecture in the config file.
You should assume the kernel appended CFLAGS are right (provided your config is ok) and if your toolchain does not support one of them, then you have no choice but to cross compile a toolchain by yourself, using the original crosstol script that should work with 2.95.3
Edit : original answer
What are you trying to build ?
a 2.95.3 toolchain is fairly ancient. You should try a more recent toolchain. You can find a precompiled one here
Pick the EABI one to start.
This is not a direct answer to your problem, but if you are building the linux kernel, you should not need to mess with the Makefiles. You will get more help if you can get a more "standard" toolchain.
This won't strictly help you eliminate the issue, but you can do gcc -dM -E <empty_file.c> or gcc -dM -E -x c /dev/null to print out a listing of all the predefined #defines for gcc. Combine -dM with another flag like your -march and you might be able to track down what's causing your #define issue.
Be sure to check your environment variables, as they can persuade make to do unexpected things.
If the Makefile includes another file, it could be modifying CFLAGS before CC is called. Can you print the contents of CFLAGS just before the CC call?

Resources