To reduce the relocation, "-BSymbolic" can be used in gcc toolchain. But how about for the armlink ? is there similar option ?
--symbolic from armlink. But it seems with different impl. with gcc.
Related
I wonder if it's possible to specify a linker option from code? Compilers allow #pragma directives to suppress warnings; how far can we extend this?
(I'm considering implicitly linking on Linux systems and using the GCC compiler; you probably could adapt the answer to your OS)
No, it is impossible to specify link options in code, and notice that the linker is working on object files (not on individual functions inside them).
However, your build procedure could extract linker options from the source code. For instance, if you have a directory with many single-source programs (that is, aa.cc C++ source file compiled into aa.bin executable, bb.cc compiled into bb.bin, etc) you might have a Makefile mentioning
%.bin: %.cc
$(CXX) $(CXXFLAGS) $(shell awk /Link:/{print $2} $<) $^ -o $#
and in aa.cc a comment like:
/* the link option is
Link: -lfoo
*/
BTW, you might also have some GCC plugin which registers and handles your specific #pragma; If you use clang instead of gcc you can also have some Clang plugin; that new pragma could add something in a common Sqlite database which is later used at link time.
So you could do sophisticated things, but I would simply suggest to have your own make rules to handle your linking.
There is an option '-fshort-double' in GCC, Clang does not understand it. Is there some analog of this option for Clang 3.7 ?
in looking at the web page: https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html#Option-Summary,
there is no -fshort-double option in gcc.
therefore, the option is not valid to begin with.
suggest removing that option when changing to clang
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.
XL Compiler of AIX seems to have the -qfuncsect option which places each function in a seperate object control section with the effect that when the final executable is created it helps in removing unwanted functions.
Is there an equivalent option for the same in gcc? I am unable to find the same.
-ffunction-sections
-fdata-sections
http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Optimize-Options.html
See -ffunction-sections
I am creating a utility which depends on libassuan aside other depends. While these ‘others’ provide shared libraries, libassuan comes with static one only.
libassuan comes with simple libassuan-config tool which is meant to provide CFLAGS & LDFLAGS for the compiler/linker to use. These LDFLAGS refer to the library as -lassuan.
The result of standard call of make is then:
cc -I/usr/include/libmirage -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -lmirage -lglib-2.0 -L/usr/lib64 -lassuan -o mirage2iso mirage2iso.c mirage-getopt.o mirage-wrapper.o mirage-password.o
mirage-password.o: In function `mirage_input_password':
mirage-password.c:(.text+0x1f): undefined reference to `assuan_pipe_connect'
mirage-password.c:(.text+0x32): undefined reference to `assuan_strerror'
collect2: ld returned 1 exit status
make: *** [mirage2iso] Error 1
(I've just started writing this unit and that's why there aren't more errors)
So, if I understand the result correctly, gcc doesn't want to link the app to libassuan.a.
Using -static here will cause gcc to prefer static libraries over shared which is unindented. I've seen solution suggesting using something like that:
-Wl,-Bstatic -lassuan -Wl,-Bdynamic
but I don't think it would be a portable one.
I think the best solution would be to provide full path to the static library file but libassuan-config doesn't provide much of help (all I can get from it is -L/usr/lib64 -lassuan).
Maybe I should just try to create the static library path by ‘parsing’ returned LDFLAGS and using -L for the directory name and -l for the library name — and then hoping that in all cases libassuan-config will return it like that.
What do you think about that? Is there any good, simple and portable solution to resolve the issue?
PS. Please note that although I'm referring to gcc here, I would like to use something that will work fine with other compilers.
PS2. One additional question: if package does install static library only, returning such LDFLAGS instead of full .la path can be considered as a bug?
gcc will link to libassuan.a if it doesn't find libassuan.so
It's probably the order symbols are looked up in the static library when you link. The order matters.
)
Assuming gcc can find libassuan.a and it actually provides the functions the linker complains about, try:
cc -I/usr/include/libmirage -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -lmirage -lglib-2.0 -L/usr/lib64 -o mirage2iso mirage2iso.c mirage-getopt.o mirage-wrapper.o mirage-password.o -lassuan
Since you say libassuan is under /usr/lib64 it's probably a 64 bit library, are your app and the other libraries 64 bit as well ?
Compiler's command-line options are not a portable thing. There's no standard for it. Every compiler uses its own and several can merely informally agree to comply with each other in command-line format. The most portable way for your linking is to use libassuan-config, of course. I think, it can generate not only flags for gcc, but for other compilers as well. If it can't, then no portable way exists, I suppose (other than CMake or something on higher level).
The command line to cc you shown is totally correct. If you have a static library libassuan.la and path to it is supplied to -L option, then the compiler does link against it. You can see it from its output: has it not found the static library, would it complain with error message like "can't find -lassuan". I
Moreover, if no libassuan.so is found, then compiler links against your library statically, even if you haven't used -Wl,-Bstatic stuff or -static flag.
Your problem may be in persistence of several versions of libassuan in your system. Other that that, I don't see any errors in what you've provided.
Which directory is libassuan.a in
I think the first error is not gcc doesn't want to link the app to libassuan.a it is more gcc does not know where libassuan.a . You need to pass gcc a -L parameter giving the path to libassuan.a .
e.g.
-L /home/path