I am going to call a C++ function from FORTRAN, for which I am using ISO_C_Binding module. After compaction of the FORTRAN main file and C++ function with commands
gfortran -c mlp8.f90
g++ -c mean_cpp.cc
Which will create the objects files but in the linking phase as suggested by some members I am going to use the commands
g++ mlp8.o mean_cpp.o -o main –lgfortran
I.e. using C++ compiler with linking to FORTRAN libraries but it gives error like
/Cygnus/cygwin-b20/H-i586-cygwin32/i586-win32/bin/ld:
cannot open –lgfortran: No such a file or directory
Collect2:ld return 1 exit status
So I think the main problem is that the g++ linker can not link with the FORTRAN libraries, so may be I need to include some path in the linking option or may be I need to do some setting in the g++ complier, which I don’t know how to do this, so please help to sort out this problem.
You should find file libgfortran.* (e.g. with locate of find / -name "libgfortran.*"; or in windows-way Win+g, F3 or any file manager), record the path where it is and do
g++ mlp8.o mean_cpp.o -o main -LPATH_RECORDED –lgfortran
where PATH_RECORDED is the path.
Try this lib list (got it from my mingw gfortran with -v option)
g++ mlp8.o mean_cpp.o -o main -LPATH_RECORDED –lgfortran -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt
Related
I have static library lib.a and in all tutorials using:
gcc -o main main.o -L. -lib
But I cant, I have errors:
/usr/bin/ld: cannot find -lib
collect2: error: ld returned 1 exit status
I need to use:
gcc -o main main.o -L. -lib.a
Why? What should I do to repair it ?
From the documentation of gcc -l:
-llibrary:
The linker searches a standard list of directories for the library, which is actually a file named liblibrary.a. The linker then uses this file as if it had been specified precisely by name.
...
The only difference between using an -l option and specifying a file name is that -l surrounds library with ‘lib’ and ‘.a’ and searches several directories.
So you cannot use -l with a library named 'lib.a'. Use 'lib.a' without the -l to include it. Of course, you cannot use -L then to set the directories to be searched for this particular library.
Do you have the error with this line ?
gcc -o main main.o -L. -llib
As MicroVirus found in the documentation, you will have to rename your library in liblib.a to use my previous line or just pass your library to gcc like a simple file.
I'm trying to compile and link some .c file. I have been using Eclipse IDE for C/C++ developers, and in my local machine i can compile without problems. However, when i try to compile and link the same file in a RedHat OS (gcc version is 4.9.2-6 in this OS) i'm having problems. I get some warnings at compile time, but those are fine, i think, i just ignored and the application still runs fine. Here are the commands i executed and the associated output:
gcc -O0 -g3 -Wall -c -fmessage-length=0 -std=c99 -MMD -MP -MF"example.d" -MT"example.d" -o "example.o" "example.c"
warning: suggest parentheses around assignment used as truth value [-Wparentheses]
warning: implicit declaration of function ‘wait’ [-Wimplicit-function-declaration]
This generates two files, example.d and example.o. Then, i try to link them, without luck, with the following command:
gcc -Xlinker -L/usr/lib -lrt -static -pthread example.o -o example
/usr/bin/ld: cannot find -lrt
/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
The commands are taken directly from the ones that Eclipse generates, and work just fine in my local computer (Ubuntu OS) but not in the RedHat environment. The last command didn't work, with and without the -L option. I suppose the directory in -L is fine, as i run, for example,
locate libpthread.so
And one of the locations i get is /usr/lib (also /usr/lib64, but neither work).
Any help will be greatly appreciated!! :)
If you try to link a static executable, it will look for the *.a versions of the libraries, not what you usually want. Remove the -static flag. Or you can install the static libraries if you really want to. It also should not be necessary to add -L/usr/lib explicitly.
My program uses the GNU Multiple Precision Arithmetic Library to deal with numbers of an arbitrary size. I successfully compile it using GCC with:
gcc main.c -o diff -g -lgmp
However, when I try to use the MinGW crosscompiler compiler, I get the following error:
i686-w64-mingw32-gcc main.c -o diff.exe -g -lgmp
main.c:3:46: fatal error: gmp.h: No such file or directory
#include <gmp.h>//For files of arbitrary size
I then tried to tell it exactly where the header file was:
i686-w64-mingw32-gcc main.c -o diff.exe -I/usr/include -g -lgmp
/usr/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/bin/ld: cannot find -lgmp
collect2: error: ld returned 1 exit status
Ok, so I figure now it successfully found the header, but cant find the library. So I tried again:
i686-w64-mingw32-gcc main.c -o diff.exe -I/usr/include -g -L/usr/lib -lgmp
/usr/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/bin/ld: cannot find -lgmp
collect2: error: ld returned 1 exit status
I guess I need to specify the exact files to use, so I tried this:
i686-w64-mingw32-gcc main.c -o diff.exe -I/usr/include -g /usr/lib/libgmp.so
/usr/lib/libgmp.so: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
So, I honestly don't know what to do and I'd really really appreciate your help.
First, a disclaimer: the cross-compiler you are using is neither distributed by, nor supported by MinGW.org, whom I represent; if you are looking for a pre-compiled solution, you should seek it from the distributor of the specific cross-compiler itself.
That said, I can offer the following insight, (which will apply, in general, to any cross-compiler): the headers you find in /usr/include, or in /usr/local/include, and the libgmp.so which you find in /usr/lib, or in /usr/local/lib, are intended for use with your native platform compiler. They are not suitable for, and cannot be used with your MinGW cross-compiler; attempting to do so will surely never work. Thus, you have two options:
Ask your cross-compiler distributor to provide a pre-compiled copy of gmp.dll, (or at the very least, a compatible import library, although you may need the gmp.dll to distribute with your own application anyway), and any associated header files, and/or equivalent statically linkable library, for use with your cross-compiler.
Use your cross-compiler to build gmp.dll yourself, then install it, its associated headers, and perhaps also its associated import library and/or equivalent statically linkable library, into the same prefix-path as the cross-compiler itself.
I am working on embedded software for a ARM microcontroller (SAM7) and using Yagarto toolchain.
My code currently links libc.a. However I'd like to use a custom implementation of the builtin function memcpy that my code already has.
I have tried using -fno-builtin and/or -fno-builtin-memcpy as specified in the GCC Manual but the linker still complains will the following warning:
contiki-crazy-horse.a(flashd_efc.o): In function `memcpy':
C:\Users\Melvin\GitRepo\projects\Amatis_Project\SAM7_Contiki\examples\er-rest-example/../../cpu/arm//at91sam7s-x/./flashd_efc.c:669: multiple definition of `memcpy'
c:/toolchains/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libc.a(lib_a-memcpy.o):C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\string/../../../../../newlib-1.19.0/newlib/libc/string/memcpy.c:78: first defined here
collect2: ld returned 1 exit status
make: *** [rest-server-example-nosyms.crazy-horse] Error 1
../../cpu/arm/at91sam7s-x/Makefile.at91sam7s-x:181: recipe for target `rest-server-example-nosyms.crazy-horse' failed
What is the correct way to use custom implementations of certain gcc built-in functions?
Edit 1: Adding the linking command I am using. In the code below Porject.a is an archive file created with all the project's object files.
CC = arm-none-eabi-gcc
CFLAGSNO = -I. -I$(CONTIKI)/core -I$(CONTIKI_CPU) -I$(CONTIKI_CPU)/loader \
-I$(CONTIKI_CPU)/dbg-io \
-I$(CONTIKI)/platform/$(TARGET) \
${addprefix -I,$(APPDIRS)} \
-DWITH_UIP -DWITH_ASCII -DMCK=$(MCK) \
-Wall $(ARCH_FLAGS) -g -D SUBTARGET=$(SUBTARGET)
CFLAGS += $(CFLAGSNO) -O -DRUN_AS_SYSTEM -DROM_RUN -ffunction-sections
LDFLAGS += -L $(CONTIKI_CPU) --verbose -T $(LINKERSCRIPT) -nostartfiles -Wl,-Map,$(TARGET).map
$(CC) $(LDFLAGS) $(CFLAGS) -nostartfiles -o project.elf -lc Project.a
If it is finding memcpy() in libc.a, then it is not conflicting with any "built-in", but rather with the newlib implementation. You may need also to specify -nostdlibs option and explicitly link libc.a and libm.a as necessary.
Object (.o) files are linked before library archives (.a) files are searched, so if a symbol is resolved by an object file, it will not be searched for in the archives. If you place your overrides in an static-link library, then you simply list it ahead of the standard library (or any other libraries that use the standard library) on the linker command line.
[Added] The following was originally a "comment" but should probably be in the answer; it is in response to "Edit 1" in the question, and the comment below about link order:
Change -nostartfiles -o project.elf -lc Project.a to -nostdlib -o project.elf -start-group Project.a -lc -end-group. The switch -nostdlib disables default linking of both start-up files (i.e. -nostartfiles) and standard libraries. The library grouping causes the libraries in the group to be searched iteratively until no further symbols can be resolved, allowing out-of-order and circular dependencies like yours to be resolved. An alternative form for the grouping switches is -( Project.a -lc -).
Good morning,
I'm trying to build luabind using bjam binaries and g++ (mingw).
Lua root is in 'D:\Dev\lua-5.1.4\',
*.a file here: 'D:\Dev\lua-5.1.4\lib\libluadll.dll.a'
*.dll file here: 'D:\Dev\lua-5.1.4\lib\luadll.dll'
All these *.o files were compiled well, but when it started linking it, something went wrong:
gcc.link.dll bin\gcc-mingw-4.4.1\debug\libluabindd.dll.a
d:/programms/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/b
in/ld.exe: cannot find -llibluadll.dll.a
collect2: ld returned 1 exit status
"g++" -L"D:\Dev\lua-5.1.4\lib" "-Wl,--out-implib,bin\gcc-mingw-4.4.1\debug\
libluabindd.dll.a" -o "bin\gcc-mingw-4.4.1\debug\libluabindd.dll" -shared -Wl,-
-start-group "bin\gcc-mingw-4.4.1\debug\src\class.o" "bin\gcc-mingw-4.4.1\debug\
src\class_info.o" "bin\gcc-mingw-4.4.1\debug\src\class_registry.o" "bin\gcc-ming
w-4.4.1\debug\src\class_rep.o" "bin\gcc-mingw-4.4.1\debug\src\create_class.o" "b
in\gcc-mingw-4.4.1\debug\src\error.o" "bin\gcc-mingw-4.4.1\debug\src\exception_h
andler.o" "bin\gcc-mingw-4.4.1\debug\src\function.o" "bin\gcc-mingw-4.4.1\debug\
src\inheritance.o" "bin\gcc-mingw-4.4.1\debug\src\link_compatibility.o" "bin\gcc
-mingw-4.4.1\debug\src\object_rep.o" "bin\gcc-mingw-4.4.1\debug\src\open.o" "bin
\gcc-mingw-4.4.1\debug\src\pcall.o" "bin\gcc-mingw-4.4.1\debug\src\scope.o" "bin
\gcc-mingw-4.4.1\debug\src\stack_content_by_name.o" "bin\gcc-mingw-4.4.1\debug\s
rc\weak_ref.o" "bin\gcc-mingw-4.4.1\debug\src\wrapper_base.o" -Wl,-Bstatic -Wl
,-Bdynamic -llibluadll.dll.a -Wl,--end-group -g
...failed gcc.link.dll bin\gcc-mingw-4.4.1\debug\libluabindd.dll.a bin\gcc-mingw
-4.4.1\debug\libluabindd.dll...
...failed updating 2 targets...
So, I renamed libluadll.dll.a into lua5.1, lua5.1.a, but it's still prints the same error message.
Thanks, beforehand.
Firstly, -l{name} directive searches for lib{name}.dll and lib{name}.a. So, yours should be -llua, not -llibluadll.dll.a.
Secondly, are Lua libraries compiled with g++ too? Object files and libraries compiled by different compilers are incompatible in general.
This part of the g++ command line is wrong:
-llibluadll.dll.a
If you want to link against libfoo.dll, the right linker flag is -lfoo (no lib, no dll).
If you have a static archive and you want a static link, just name the archive, with no -l prefix (and specify a path if it's not found).