I am reading my build scripts of my project and found a place where it is written the following command
objcopy --redefine-sym =.L.str before.a after.a
Could somebody please explain me what does .L.str mean here?
Related
I'm working on a toy bootloader/kernel written in assembly and run on the qemu emulator. I can run qemu with -s -S option and debug with gdb using remote target, but I don't have any debug symbols loaded with gdb. How can I generate a symbol file from my assembly?
I'm using nasm to generate a binary image for qemu to run from my assembly file, but I haven't found anyway to include debug information in the image itself (I'm not sure if that even makes sense). I also found that gdb allows you to load an separate symbol file for debugging, so now my issue is how to generate a symbol file from my assembly code.
I've seen suggestions to use objcopy, but I believe that only works on elf files, not binary. I've tried getting nasm to generate an elf, but it keeps barfing because of my (necessary) org directive in the assembly file.
It would say try it like this:
use "-f elf -F dwarf -g" switches when assembling. This should produce elf file that contains debug symbols (and code and everything else).
Use objcopy to generate binary file.
Load binary file to your system.
Attach debugger, then tell it to load symbols from your .elf file (symbol-file yourfile.elf)
You need to solve why nasm can't generate .elf file with .org you have in there. I have no idea. GNA as is fine with this.
$ nasm -g -f elf64 -l 2.lst 2.asm
$ gcc -m64 -o 2.exe 2.o
I tried to use NetBeans+OpenCV+cmake+mingw to run KAZE_features.cpp.
I had already added up all the libraries to linker, including all files of opencv_(&&&).exe.
g++.exe -o dist/Debug/MinGW-Windows/welcome_1 build/Debug/MinGW-Windows/_ext/571919051/kaze_features.o -L../build/x64/mingw/bin -L../build/x64/mingw/lib -L../build/x64/vc10/bin -L../build/x64/vc10/lib -lopencv_createsamples.exe -lopencv_haartraining.exe -lopencv_perf_calib3d.exe
But when I tried to debug the cpp, it kept show up thses errors:
c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/bin/ld.exe: cannot find -lopencv_createsamples.exe
Did I add .exe files to wrong place?? Anyone can give me an idea what s wrong here?
Thank you very much!!!
The -l option is used to add libraries, but these .exe aren't libraries. It's just a test generated by the openCV compilation. Have you tried removing -lopencv_createsamples.exe -lopencv_haartraining.exe -lopencv_perf_calib3d.exe ?
If this doesn't works, try to add all the librairies manually like this : -lopencv_core245 -lopencv_highgui245 ...
I'm working on a toy bootloader/kernel written in assembly and run on the qemu emulator. I can run qemu with -s -S option and debug with gdb using remote target, but I don't have any debug symbols loaded with gdb. How can I generate a symbol file from my assembly?
I'm using nasm to generate a binary image for qemu to run from my assembly file, but I haven't found anyway to include debug information in the image itself (I'm not sure if that even makes sense). I also found that gdb allows you to load an separate symbol file for debugging, so now my issue is how to generate a symbol file from my assembly code.
I've seen suggestions to use objcopy, but I believe that only works on elf files, not binary. I've tried getting nasm to generate an elf, but it keeps barfing because of my (necessary) org directive in the assembly file.
It would say try it like this:
use "-f elf -F dwarf -g" switches when assembling. This should produce elf file that contains debug symbols (and code and everything else).
Use objcopy to generate binary file.
Load binary file to your system.
Attach debugger, then tell it to load symbols from your .elf file (symbol-file yourfile.elf)
You need to solve why nasm can't generate .elf file with .org you have in there. I have no idea. GNA as is fine with this.
$ nasm -g -f elf64 -l 2.lst 2.asm
$ gcc -m64 -o 2.exe 2.o
Normally it happens that when ever the path of the library that has to be linked dynamically is defined in LD_LIBRARY_PATH or it it will be mentioned with -L flag while creating the binary.
In actual scenario if ,lets say the binary has been built and deployed at the client place.
Now if there is a change in the path of one of the dynamic link library path.
then we need to supply a new make file to all the clients where the binary was deployed.
is there any other method where we need not tell all the clients to change their makefiles and can something can be done in the code itself?
if yes...could anybody please suggest how?
This was ironically an interview question that was asked to me and i didnot have the answer for it.
EDIT:: I was specifically asked about what can be done in the code without touching the makefile.
Usually you should only change the LD_LIBRARY_PATH, unless this might be related to a compilation with a hard-coded search path: rpath.
Maybe the interviewers wanted to know about dlopen and dlsym?
http://linux.die.net/man/3/dlsym
Use environment variable, like MYLIBPATH, and use this variable in your makefile, rather than hard-coded value.
So every client can have own directory structure, and as long as they correctly specify MYLIBPATH, your program builds ok.
Alternatively you can look for library in your makefile, like this
LIBPATH = $(shell find / -name libmylib.a -exec dirname {} ";" -quit)
myprog: myprog.c
$(CC) myprog.c -lmylib -L$(LIBPATH)
EDIT: locate replaced with find that returns just first match with -quit option
I am on OS X + Python 2.6 + django 1.1.
I have tried all possible solution available on the net i.e.
http://thingsilearned.com/2009/01/02/installing-csstidy-and-scons-on-os-x-or-linux/
tried with python 2.5, 2.4 apple-python.. I just can't go past this error after installing scons
$ /usr/local/bin/scons
scons: *** No SConstruct file found.
File "/Library/Python/2.5/site-packages/SCons/Script/Main.py", line 829, in _main
I need csstidy for django-compress (yes I can turn that function off but why?) I mean the maintainer must see some value to have it in default and he knows better.
Unfortunately there is no port for csstidy...
Don't know if you managed to give up or not, or if you solved it.
For anybody who is still having trouble building CSSTidy, here was my solution. If you follow the tutorial in the URL linked above, there is one horrible error in it that I didn't realize until about an hour later.
$ wget http://downloads.sourceforge.net/csstidy/csstidy-source-1.4.zip?modtime=1184828155&big_mirror=0
$ unzip csstidy-source-1.4.zip
$ cd csstidy <<-- THIS IS WRONG. SConstruct isn't here. D:
$ scons
$ sudo cp release/csstidy/csstidy /usr/local/bin/
The errors the author ran into had nothing to do with the --standard-lib flag. When you unzip, the files don't get put into a subdirectory like tar usually does. So the SConstruct file that's magically missing is actually in the directory above csstidy, wherever you ran unzip in the first place.
Once I found that out, I saw the SConstruct file and was able to build it by running scons.
If you just want to build csstidy and don't care about incremental builds, just do this:
g++ *.cpp -o csstidy