I know the -l and -L options for link but I am looking to set the --start-group and --end-group and all my libraries into my C project (Properties) under CDT/Juno but where do I put this option ????
-Xlinker ?
Thanks
Marc
You can insert this options through "Expert settings: Command line patterns".
To insert the options -Wl,--start-group and -Wl,--end-group you can edit this field. Follow the steps below:
Click in the option GCC C/C++ Linker
Edit the field Command line pattern
from
${COMMAND} ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}
to
${COMMAND} ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} $(OBJS) -Wl,--start-group $(USER_OBJS) -Wl,--end-group $(LIBS)
Notice that we are open the variable ${INPUTS} that's equal INPUT="$(OBJS) $(USER_OBJS) $(LIBS)". Check the result in the makefile generated.
Insert your static files in the section GCC C/C++ Linker -> Miscellaneous -> Other objects.
I ran into this same issue - a quick workaround I used was to make the first entry in my toolchain linker "other objects" list the value "-Wl,--start-group" and the last entry "-Wl,--end-group".
Related
I need to make a library for a customer who is using GCC. I have a working Keil project compiled with the GCC. The next step is to make a library. I removed from the project main file and Keil generated libname.a library file. Now I want to create a new project with the same main and libname.a library. I'm failing to do so. I added this library to Options/Linker tab, added library path and getting "c:/gnu arm embedded toolchain/10p3_2021_10/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld.exe: cannot find -llibname.a
Here is all the options/flags:
-mcpu=cortex-m4 -mthumb -o ./DebugConfig/name_main.elf -L ./DebugConfig *.o -llibname.a -mcpu=cortex-m4 --specs=nosys.specs -Wl,--gc-sections -static -Wl,--start-group -Wl,--end-group --specs=nano.specs -mthumb -Wl,--start-group -lc -lm -Wl,--end-group
Thank you in advance.
All that was needed is to put a colon in front of the name :libname.a ...
I hate fighting with tools.
Here is the solution: I need to add into the misc section separately -L path\lib\one -l libname
Or -l:name.a
I did not find where it is written that my options are:
-l name and in this case libname.a file will be searched for;
-l:name.a and in this case name.a file is the target library.
Why does it have to be so convoluted and complicated... This is just a rhetorical question, obviously. I hope this will help someone else in the future.
My original question is below, but it evolved to the following related question: is there anything wrong with putting linker flags after the objects in the linker statement?
When I build in Eclipse, the following linking statement is run:
g++ -fopenmp -lconfig++ -o "pc2" ./main.o ./sampling.o ./simulation.o
which is incorrect, because lconfig++ must follow, not precede, the object file listing. So, I modified the makefile, which was automatically generated by Eclipse based on the project settings. Specifically, I changed this portion of the makefile
# Tool invocations
pc2: $(OBJS) $(USER_OBJS)
#echo 'Building target: $#'
#echo 'Invoking: GCC C++ Linker'
g++ -fopenmp -lconfig++ -o "pc2" $(OBJS) $(USER_OBJS) $(LIBS)
#echo 'Finished building target: $#'
#echo ' '
to be as follows:
# Tool invocations
pc2: $(OBJS) $(USER_OBJS)
#echo 'Building target: $#'
#echo 'Invoking: GCC C++ Linker'
g++ -o "pc2" $(OBJS) $(USER_OBJS) $(LIBS) -fopenmp -lconfig++
#echo 'Finished building target: $#'
#echo ' '
Then, after modifying that 1 line of the makefile, I entered
make clean all -C release
at the command line, which produced the following correct linking statement:
g++ -o "pc2" ./main.o ./sampling.o ./simulation.o -fopenmp -lconfig++
Therefore, I know how to fix the makefile so that the build process is correct.
What I do not know is how to configure Eclipse so that the makefile it generates places the linker flags (or "options"?) at the correct location.
You've answered your own question: yes, the order of objects and libraries on the link line does matter.
is there any reason why I might need linker flags to precede the object files?
There may well exist such linker flags. For example --start-group GNU-ld linker options must (obviously) precede the library group it starts. The --start-lib Gold linker option must (obviously) precede the objects that form a library, etc.
I discovered that I could move ${FLAGS} in settings
You likely have included -lconfig++ in the ${FLAGS} somewhere in Eclipse, and that's likely a mistake -- the -lconfig++ is not a linker flag (even though it looks like one), it's a library specification, and should probably be included in ${LIBS} or some such.
I have to ship a third-party library with an application. Because I don't want to set LD_LIBRARY_PATH by hand or require any wrapper script I want automake to set a custom rpath. Unfortunately libtool has its own -rpath option and adding -Wl,-rpath,/foo/bar to LDFLAGS only results in
g++: unrecognized option '-rpath'
because libtool seems to get confused with the command line options. The same happens with the alternative form -Wl,-rpath -Wl,/foo/bar.
Is there any way to specify a custom rpath without libtool interference?
As you said, libtool has its own -rpath option. Any reason you don't want to use it?
% libtool link g++ foo.cc -o foo -rpath /somewhere
libtool: link: g++ foo.cc -o foo -Wl,-rpath -Wl,/somewhere
% readelf -d foo | grep RPATH
0x000000000000000f (RPATH) Library rpath: [/somewhere]
None of the examples in the Automake or Libtool manuals use -Wl to specify -rpath.
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 -).
I'm cross-compiling an application, but linking blows up with an error that it
"cannot find /lib/libc.so.6".
The libc.so.6 that it should be using is the one that sits at /home/work/worldcom/filesys/lib/libc.so.6. What have I got wrong here?
linking libobj.so
arm-none-linux-gnueabi-g++ obj1.o obj2.o obj2.o -o libobj.so -L/home/work/worldcom/filesys/usr -Wl,-O1 -Wl,-z,defs -Wl,--enable-new-dtags -Wl,--sort-common -Wl,--as-needed -Wl,--hash-style=both -L/home/work/worldcom/filesys -L/home/work/worldcom/filesys/lib -L/home/work/worldcom/filesys/usr/lib -lcurl -shared
/home/lishevita/armv5tel/arm-2009q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
/home/lishevita/armv5tel/arm-2009q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: cannot find /lib/libc.so.6
collect2: ld returned 1 exit status<br />
make: *** [libobj.so] Error 1<br />
My makefile is handwritten (i.e. not generated by Autotools). In order to avoid a blanket "your Makefile is broken" here are some details from the makefile that might help clarify.
CROSS_COMPILE = arm-none-linux-gnueabi-
SYSROOT = /home/work/worldcom/filesys/
DESTDIR = /home/work/worldcom/filesys/
RELEASE_CXXFLAGS = -Os
DEBUG_CXXFLAGS = -O0 -gstabs
PKGCONFIG=`env ROOT=/home/work/worldcom/filesys cross-pkg-config glib-2.0 libcurl --cflags`
CC = $(CROSS_COMPILE)gcc
CXX = $(CROSS_COMPILE)g++
LD = $(CROSS_COMPILE)ld
AR = $(CROSS_COMPILE)ar
LDFLAGS = -Wl,-O1 -Wl,-z,defs -Wl,--enable-new-dtags -Wl,--sort-common -Wl,--as-needed -Wl,--hash-style=both -L$(SYSROOT) -L$(SYSROOT)lib -L$(SYSROOT)usr -L$(SYSROOT)usr/lib -lcurl
libobj.so: $(LIBOBJ_OBJS)
#echo linking $#
$(CXX) $^ -o $# $(LDFLAGS) -shared $(PKG_LIBS)
Of course there is also a definition and target for the LIBOBJ_OBJS but those are irrelevant to the problem.
You didn't indicate what gcc version you are using, but if it is a recent enough one (4.0.0 and above me thinks) you should try adding the --sysroot flag to g++/ld. Point it to $SYSROOT as defined in your Makefile. For example:
--sysroot=$(SYSROOT)
Assuming recent enough gcc version, it will work.
I just went through the same issue; adding --sysroot=/rootfs/prefix helped me get closer to the real issue. I got it fixed by installing package libstdc++-dev in target.
Have you not considered that possibly the LIBPATH is set and hard-coded to look for the /lib/libc.so.6 and therefore the /lib path?
Have you tried to set the environment variable like this on the command line, prior to issuing make when cross-compiling:
LIBPATH=/home/work/worldcom/filesys/lib
In your specific case, as you have mentioned in the tag 'cross-compiling', it might be worth it to remove any references to /lib to wholly force the linker to look in your own home directory instead as not to interfere with the cross-compile process.
The other possibility is that the gcc compiler when it was built for your environment, the configuration during the building of the compiler from source, was specified to point to the /lib path.
Hope this helps,
Best regards,
Tom.
It seems that the makefile is broken, because the libc.so.6 is assumed to be located in the /lib/ folder (note the preceding slash indicating an absolute path! ). This seems to be the issue.