I have a QT application with bugsplat integrated therefore I need the DSYM in case we have a crash, but I also want to make cracking more difficult, some of the first steps are striping the method names.
I'm generating the DSYM with these lines:
CONFIG += debug_and_release
CONFIG += force_debug_info
CONFIG += separate_debug_info
I managed to strip the symbols with following the commands recommended by this link :
QMAKE_CFLAGS_RELEASE += -Xlinker -unexported_symbol -Xlinker "*"
strip executable
unfortunately the DSYM file becomes unusable after the strip command (at least that's what Hope Disassembler tells me), if I remove the second command I can still see the method names in the disassembler.
in the strip wiki I can read the following:
The effect of strip can be achieved directly by the linker. For
instance, in GNU Compiler Collection this option is "-s".
I've already tried all sorts of flags combinations
Hide function name in GCC compilation
gcc vs. clang: symbol stripping
But it seems the linker detects when is working with persons that know nothing about these subjects and ignores all my attempts.
Note I'm doing this for mac right now but after this step I need to do it in windows as well.
The compiler being used is: clang++
Related
To learn the processes behind compilation of Ada programs (without resorting to using gpr), I've decided to compile one of my projects manually. To compile a program, I run the following command on each .adb file therein (not manually, however):
$ gcc -c src/<file>.adb -o obj/<file>.o
That compiles all the files and puts them in the obj directory.
Or rather, it would. There is a slight problem with this. I have an archive (static library) that I've generated from another project, called libapples.a, containing package Apples. The Apples package is used by the files you see me compiling above.
Since libapples.a doesn't have source files anymore (given its archive format), it's not viable (not even possible) to provide the sources of that library to the command above using -I switches; on the other hand, if I don't have the sources included, the command above comes back to me saying:
<file>.adb:<y>:<x>: file "apples.ads" not found
gnatmake: "src/<file>.adb" compilation error
I've attempted to include the library in the compilation process by using flags -L and l (which I believe is how you'd do it in C; feel free to correct me if I'm wrong). In another attempt I placed the archive right in the source directory.
How does one go about including a library in the compilation process?
apples.ads is somewhat like a header in C and you definitely need it for your file to compile. You should use -I to point gcc to the directory where apples.ads is located in.
Be aware that compiling an Ada source not only yields an object file, but also an Ada Library Information (.ali) file. You'll need that for the next step. You should not use the -o flag because it may lead to your .o and .ali files having different names.
On the other hand, since you only want to produce an object file, you should use -c to tell gcc to only compile. In other languages like C, gcc compiles and links by default; in Ada, the process is more complex.
After compilation, you need to call gnatbind on the .ali file of your main program. This generates a package that will take care of proper initialization of everything. To do that, gnatbind needs the .ali file of the Apples package! You can specify the .ali search directory with -aO.
Finally, gnatlink called on the main .ali file will link everything together. It figures out itself which object files and libraries it needs. It will append the necessary options to the linker, including the reference to libapples.a. It also compiles the package generated by gnatlink.
I don't know exactly what gnatlink will do under the hood; you could probably compile the package generated by gnatbind manually and then call the linker if you can figure out the proper arguments.
I've a master project with many sobprojects, that I compile using qmake.
In a sub-project I must copy some files before compilation (some header file). I've seen some command to perform operation before and after linking, but I'd like to know if it's possible to perform some shell operation before start compilation. I can't refer to them, but I must to copy them (don't ask why please, it's not my fault :-( ). Any suggestion?
Thanks in advance for your replies.
see my last answer on nearly the same question:
Copy some file to the build directory after compiling project with Qt
the only difference for you is to change in point 5:
POST_TARGETDEPS += copyfiles ## copy files after source compilation
to:
PRE_TARGETDEPS += copyfiles ## copy files before source compilation
when executing qmake there have to exist all files already in filesystem before
I think what you want to do can be accomplished with careful use of the QMAKE_EXTRA_COMPILERS and QMAKE_EXTRA_TARGETS variables. The Qt Labs article The Power of QMake gives a reasonable introduction to it. The ".commands" part of the extra compiler can be any arbitrary command, including a shell command.
The other suggestion I found in this e-mail exchange is to "... take a look at mkspecs/features/*.prf - especially those of moc and uic.." for other possible ways to do it.
I also just played around with QMAKE_EXTRA_TARGETS to solve the question, but could not manage to get it done ;)
One other (simple) solution which might work for you is to wrap the call to gcc/g++: in the .pro file, set QMAKE_CXX=./g++Wrapper and in the g++Wrapper shell script, call the original compiler while doing anything you want before and after the call:
#!/bin/bash
DoWhateverYouWantBeforeCompilation
g++ $*
DoWhateverYouWantAfterCompilation
By evaluating the command line parameters, you could also restrict your actions to specific files.
After creating qt project in codeblocks and running it I'm getting:
Anyone knows how to resolve it?
Thanks
This looks to me like you're building against one version of Qt and linking against another at runtime. Run the QtSDK Maintenance Tool and remove any versions of Qt Desktop that you don't need. You may then need to repoint Codeblocks at the correct headers.
I'm guessing that if you're running from within Codeblocks, you've had to explicitly specify which dlls to use when you run your newly built app. If so, make sure that those are the correct versions (i.e. replace them with dlls from QT INSTALL DIR\Desktop\4.7.x\mingw\bin [though I'm not on my work PC at the moment, so this path may be slightly wrong. Just make sure you're in the correct 4.7.x folder]).
To be honest though, if you're running from Windows, why not use QtCreator? Aside from slightly lacking in terms of GDB integration, it's pretty good and you'd find problems like this are harder to come across.
This is (esp on Windows) a common problem. When installing the Qt SDK, you'll get at least 2 .dll's with the same name but in different versions. It happens, that you link against the intended (dev-)lib but at runtime the version from the Designer/Creator is used.
The easiest way to avoid this, is to deploy the right version of the dll's together with your binaries (.exe and stuff) in a separate folder. This can be achived by modifying your build script. It depends on your build system which is usually qmake/.pro or cmake/CMakeLists.txt.
As for CMake, given an environment variable MYQTDLLDIR containing the path to the files to be deployed you can use something like that:
configure_file($ENV{MYQTDLLDIR}/QtCore4.dll ${CMAKE_CURRENT_BINARY_DIR} COPYONLY)
configure_file($ENV{MYQTDLLDIR}/QtGui4.dll ${CMAKE_CURRENT_BINARY_DIR} COPYONLY)
documentation stripped from cmake --help-full:
configure_file Copy a file to another location and modify its
contents.
configure_file(
[COPYONLY] [ESCAPE_QUOTES] [#ONLY])
Copies a file to file and substitutes variable
values referenced in the file content. If is a relative
path it is evaluated with respect to the current source directory.
The must be a file, not a directory. If is a
relative path it is evaluated with respect to the current binary
directory. If names an existing directory the input file
is placed in that directory with its original name.
This command replaces any variables in the input file referenced as
${VAR} or #VAR# with their values as determined by CMake. If a
variable is not defined, it will be replaced with nothing. If
COPYONLY is specified, then no variable expansion will take place. If
ESCAPE_QUOTES is specified then any substituted quotes will be C-style
escaped. The file will be configured with the current values of CMake
variables. If #ONLY is specified, only variables of the form #VAR#
will be replaces and ${VAR} will be ignored. This is useful for
configuring scripts that use ${VAR}. Any occurrences of #cmakedefine
VAR will be replaced with either #define VAR or /* #undef VAR */
depending on the setting of VAR in CMake. Any occurrences of
#cmakedefine01 VAR will be replaced with either #define VAR 1 or
#define VAR 0 >depending on whether VAR evaluates to TRUE or FALSE in
CMake
As for qmake you could use INSTALLS (used when make install is called) or execute a "plain command" after linking. Using INSTALLS:
mytarget.path = /output/path
mytarget.files += /path/to/QtCore4.dll
mytarget.files += /path/to/QtGui4.dll
INSTALLS += mytarget
qmake using command execution:
win32 {
EXTRA_BINFILES += \
$${MYQTDLLDIR}/QtCore4.dll \
$${MYQTDLLDIR}/QtGui4.dll
EXTRA_BINFILES_WIN = $${EXTRA_BINFILES}
EXTRA_BINFILES_WIN ~= s,/,\\,g
DESTDIR_WIN = $${DESTDIR}
DESTDIR_WIN ~= s,/,\\,g
for(FILE,EXTRA_BINFILES_WIN){
QMAKE_POST_LINK +=$$quote(cmd /c copy /y $${FILE} $${DESTDIR_WIN}$$escape_expand(\n\t))
}
}
What changes must I make to the .pro file if I want to execute chmod command, execute the output binary file, or do some other operations.
I had a similar problem. I wanted a special tool (versioner) to run over the code every time the Makefile was executed. Here's the solution:
(to be read in the Qmake Manual, Configuring qmake's Environment, Section: Customizing Makefile Output)
Create you own Makefile target. Specify the command etc.
mytarget.target = .buildfile
mytarget.commands = touch $$mytarget.target
QMAKE_EXTRA_TARGETS += mytarget
This way, you have an extra target you can call with make mytarget for example. If you want to tie it together to the actual buildtarget you'll have to add:
POST_TARGETDEPS += mytarget
Hope that helps.
Best regards
D
Another way to make things in given order is to use empty "super" target:
super.depends = target_pre first target_post
QMAKE_EXTRA_TARGETS += super
Where first - is default qmake target, and target_pre and target_post some custom targets. Now make super just do the thing.
EDIT: looks like in last versions of Qt build of dependencies is running in paralell so this solution wouldn't work.
If you are using Qt Creator, you can add custom build steps in the Projects panel: http://doc.qt.nokia.com/qtcreator-2.1/creator-build-settings.html#adding-custom-build-steps
The right answer depends on exactly what you want, and when. However, as seen in some previously posted comments here QMAKE_POST_LINK is probably what you want rather than POST_TARGETDEPS.
Check out this related post:
QMake: execute script after build
For one, when you use POST_TARGETDEPS that fires off BEFORE your exe is created (in Windows) or BEFORE it is recreated (in Linux)! QMake works differently depending upon the platform and the complier.
I needed to do some "symbols processing" on an exe when it was recompiled. POST_TARGETDEPS gave me problems in both Windows (using mingw) and Linux (using gcc). In Windows, it executed my script prematurely, and in Linux it overwrote my exe after I had modified it (i.e. added back my debugging info to the exe after I had stripped it in my external script). QMAKE_POST_LINK worked perfectly, however, in both cases. It's also short, sweet, and more clear by comparison!
I've been trying to get a dead simple listing from a university textbook to compile with the newest QT SDK for Windows I downloaded last night. After struggling through the regular nonsense (no make.bat, need to manually add environment variables and so on) I am finally at the point where I can build. But only one of the two libraries seem to work.
The .pro file I use is dead simple:
SUBDIRS += utils \
dataobjects
TEMPLATE = subdirs
In each of these two subfolders I have the source for a library. Running QMAKE generates a makefile and running Make runs through all the preliminaries and then fails on the g++ call:
g++ -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc --out-implib,libdataobjects.a -shared -mthreads -Wl -Wl,--out-implib,c:\Users\Cobus\workspace\lib\libdataobjects.a -o ..\..\lib\dataobjects.dll object_script.dataobjects.Debug -L"c:\Users\Cobus\Portab~1\Qt\2010.02.1\qt\lib" -LC:\Users\Cobus\workspace\lib -lutils -lQtXmld4 -lQtGuid4 -lQtCored4
c:/users/cobus/portab~1/qt/2010.02.1/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/ld.exe: cannot find -lutils
The problem seems to be right near the end of the command line, where -lutils is added, indicating that there is a library by the name of utils. While I would have expected to see that, you'll notice the library names after --out include lib in the name, so they become libutils and libdataobjects. I have tried to figure out why this is happening, to no avail.
Anyone have an idea what's going on?
You .pro file uses the SUBDIRS template which requires a .pro file matching the directory name for each subdir. You should have a utils\utils.pro and dataobjects\dataobject.pro file as well.
Is c:\Users\Cobus\workspace\lib\libdataobjects.a built correctly? If not, check the sub directory .pro files.
With what you posted, I would not expect anything to compile. You need targets in the sub-directory .pro files to build anything.
Their seems to be another pro file as the generated Makefile is pulling QtXml which it wont do by default.
Please check the subdirs for any .pro or .pri files .. one of them will have answer to your confusion