With IBM's cc compiler there is one option -brtl.
cc-brtl .....
This option does the following:-
-brtl Tells the linkage editor to accept both .so and .a library file types.
I am using gcc compiler now on ubuntu. I want to know what is the corresponding option in gcc to achieve
the same thing?
You don't need that option for gcc. The link editor will accept both so and a files by default, with so files being preferred. You can think of gcc as having the opposite behaviour to IBM's C compiler: The behaviour without any options is as if you provided -brtl to IBM's C compiler, while the option -static turns of dynamic linking (and thus causes gcc to not take so files into consideration), which is as if you didn't specify -brtl to IBM's C compiler.
Related
I would like to know how to link a pgc++ compiled code (blabla.a) with a main code compiled with c++ or g++ GNU compiler.
For the moment linking with default gnu c++ linker gives errors like:
undefined reference to `__pgio_initu'
As the previous person already pointed out, PGI supports G++ name mangling when using the pgc++ command. Judging from this output, I'm guessing that you're linking with g++ rather than pgc++. I've had the most success when using pgc++ as the linker so that it finds the PGI libraries. If that's not an option, you can link an executable with pgc++ -dryrun to get the full link line and past the -L and -l options from there to get the same libraries.
Different C++ compilers use different name-mangling conventions
to generate the names that they expose to the linker, so the member function
name int A::foo(int) will be emitted to to the linker by compiler A as one string
of goobledegook, and by compiler B as quite a different string of goobledegook,
and the linker has no way of knowing they refer to the same function. Hence
you can't link object files produced by different C++ compilers unless they
employ the same name-mangling convention (and quite possibly not even then: name-mangling
is just one aspect of ABI compatibility.)
That being said, according to this document,
PGC++ supported name-mangling compatibility with g++ 3-and-half years ago, provided that PGI C++ compiler was invoked with precisely the command pgc++ or pgcpp --gnu. It may be that the library you are dealing with was not built in that specific way, or perhaps was built with an older PGI C++ compiler.
Anyhow, if g++ compiles the headers of your blabla.a and emits different
symbols from the ones in blabla.a, you can't link g++ code with blabla.a.
You'd need to rebuild blabla.a with g++, which perhaps is not an option.
I need to include all symbols from a static library. "-force_load" is good when compiling with Xcode. But, for example, when using it under Ubuntu with gcc, "-force_load" is not recognized. I'm looking for alternative options that can be used under other operating systems. Thanks.
The GNU linker's option is called --whole-archive, but while -force_load applies to one library, --whole-archive applies to all libraries after it on the command line. So the usual thing is to do --whole-archive somelib.a --no-whole-archive.
Usually you don't use ld directly but instead invoke it via GCC, in which case you have to tell GCC to pass the options on to the linker: -Wl,--whole-archive,somelib.a,--no-whole-archive
Is there any situation in which flags such as -ansi, -Wall, and -pedantic might be relevant during the linking part of the process?
What about the -O optimization flags? Are they only relevant during the compile steps or are they also relevant during linking?
Thanks!
In practice, no - but in theory, -ansi is a dialect option, so it could conceivably affect linking. I've seen similar behaviour with older versions of clang that use libc++ or libstdc++, when using C++11 or C++03 respectively. I find it easier to put these flags in the CC variable: CC = gcc -std=c99 or CC = gcc -std=c90 (ansi).
I just invoke C++ (or C) with $CXX or $CC out of habit. And they are passed by default to configure scripts.
I'm not aware of this being an issue with C, as long as the ABI and calling conventions haven't changed. C++, on the other hand, requires changes to the C++ runtime to support new language features. In either case, it's the compiler that invokes the linker with the relevant libraries.
There is link-time optimization in gcc:
-flto[=n]
This option runs the standard link-time optimizer. When invoked
with source code, it generates GIMPLE (one of GCC's internal
representations) and writes it to special ELF sections in the
object file. When the object files are linked together, all the
function bodies are read from these ELF sections and instantiated
as if they had been part of the same translation unit.
To use the link-time optimizer, -flto needs to be specified at
compile time and during the final link.
I'm writing a shared library using autoconf/libtool which I want to compile for Linux and for Windows (Using the mingw cross-compiler). For Linux (and maybe other platforms which support it) I need to set -fPIC. So I put it into the CFLAGS in Makefile.am. But when I cross-compile it with mingw then gcc complains with a warning:
warning: -fPIC ignored for target (all code is position independent)
So obviously this option is not needed for Windows code. It is only a warning but I want to get rid of it anyway. How can I do this? Maybe there is already a libtool/autoconf feature which checks if the option is supported and only sets it when needed so I don't have to do this manually in Makefile.am?
You shouldn't need to set -fPIC manually, libtool will add it if you tell it what type of binary/library you're building.
lib_LTLIBRARIES = mylibrary.la
mylibrary_la_SOURCES = mylibrary.c
This can produce both a mylibrary.so with PIC (if needed) and a mylibrary.a without, depending on other Autoconf/Automake options. (Probably something like .dll and .lib on Windows, but I don't use that platform.)
I have used the following in configure.ac to add -fPIC conditionally:
AC_MSG_CHECKING(whether fPIC compiler option is accepted)
SAVED_CFLAGS="$CFLAGS"
CFLAGS="$CFLAGS -fPIC -Werror"
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [return 0;])],
[AC_MSG_RESULT(yes)
CFLAGS="$SAVED_CFLAGS -fPIC"],
[AC_MSG_RESULT(no)
CFLAGS="$SAVED_CFLAGS"])
I used f2c to translate a huge Fortran subroutine into C. The header says the following:
/* fourier.f -- translated by f2c (version 20090411).
You must link the resulting object file with libf2c:
on Microsoft Windows system, link with libf2c.lib;
on Linux or Unix systems, link with .../path/to/libf2c.a -lm
or, if you install libf2c.a in a standard place, with -lf2c -lm
-- in that order, at the end of the command line, as in
cc *.o -lf2c -lm
Source for libf2c is in /netlib/f2c/libf2c.zip, e.g.,
http://www.netlib.org/f2c/libf2c.zip
*/
I am using ubuntu 10.04. How can I link the object file with libf2c?
You would have to install the libf2c2-dev package -- but as the f2c package already depends on it, all you may need is to add -lf2c to your Makefile.
Are you compiling the resulting C file with gcc? Then add "-lf2c -lm" to the gcc compile command.
Why not compile with a Fortran compiler, such as gfortran? It's easily available for Ubuntu.
By passing -lf2c -lm to the line which will create the executable from the objects. Which compiler are you using on Ubuntu? GCC?
gcc -c fourier.c -lf2c -lm
Could be as simple as that.
Well - no direct answer to your linking problems, but:
Since you're working with Linux: Why don't you compile you fortran code as is and link it directly with the C-code? GCC can do that. Converting the code is of course doable but it is by no way required.
Nils