I use Qt5, msvc2010, windows7 64bit.
I want to test if i can link libpq.lib.
http://www.postgresql.org/docs/9.2/static/libpq-example.html
I build the above example in QtCreator.
And get
error LNK2019: unresolved external symbol _PQconnectdb in function "_main"
I check my libpq.lib use dumpbin libpq.lib /exports
And get
1 PQconnectdb
156 PQconnectdbParams
How to See the Contents of Windows library (*.lib)
so difference is PQconnectdb and _PQconnectdb.
Is that underscore that makes the linker can't find the real symbol PQconnectdb?
Why the compiler add an underscore to the symbol?
How can I solve this problem?
Is that underscore that makes the linker can't find the real symbol
PQconnectdb? Why the compiler add an underscore to the symbol?
This is the __cdecl convention that is still in effect for x86 (32 bits) but has been obsoleted for 64 bits builds.
Since dumpbin libpq.lib /exports shows no underscores, it means that this library comes from a 64 bits build.
To produce a 32 bits program, replace your libraries with the lib directory from a 32 bits PostgreSQL zip archive. The contents will be compatible with your current build configuration that appears to be 32 bits.
On the other hand, to produce a 64 bits program, configure Qt Creator to use a 64 bits "Kit" (e.g. in Qt Creator 3, Projects tab, see Add Kit in the Build & Run panel) with the 64 bits PostgreSQL libraries you already have.
Related
I have been working on RiscV Vector extension and I have found this repo as my test processor. But since I have a memory-bound code, for reducing the latency I should change the memory width from 32 to 64 bit. My question is how does this change effect the makefile (for generating .vmem) and linker file of the processor.
Here are both files:
Makefile
Linker
I am trying to deploy a Qt application by providing the Qt libraries as shared libraries in a directory and pointing ld to them using LD_LIBRARY_PATH. This works for all Qt libraries such as libQt5Network or libQt5Gui, but not for libQt5Core which is somehow not found and the system version is used instead.
Using LD_DEBUG=all I can see that ld tries the file which exists, but skips it
3705: file=libQt5Core.so.5 [0]; needed by ./app.bin [0]
3705: find library=libQt5Core.so.5 [0]; searching
3705: search path=/home/user/app/lib:/usr/lib64/tls/x86_64/x86_64:/usr/lib64/tls/x86_64:/usr/lib64/tls/x86_64:/usr/lib64/tls:/usr/lib64/x86_64/x86_64:/usr/lib64/x86_64:/usr/lib64/x86_64:/usr/lib64 (LD_LIBRARY_PATH)
3705: trying file=/home/user/app/lib/libQt5Core.so.5 <- this file exists
3705: trying file=/usr/lib64/tls/x86_64/x86_64/libQt5Core.so.5
3705: trying file=/usr/lib64/tls/x86_64/libQt5Core.so.5
3705: trying file=/usr/lib64/tls/x86_64/libQt5Core.so.5
3705: trying file=/usr/lib64/tls/libQt5Core.so.5
3705: trying file=/usr/lib64/x86_64/x86_64/libQt5Core.so.5
3705: trying file=/usr/lib64/x86_64/libQt5Core.so.5
3705: trying file=/usr/lib64/x86_64/libQt5Core.so.5
3705: trying file=/usr/lib64/libQt5Core.so.5
Both libQt5Core.so.5 and app.bin are 64 bit elf.
Is there any way to find out why ld rejects the file?
Solution is here: https://github.com/Microsoft/WSL/issues/3023
The library contains an ABI note which can be removed using strip to make ld accept the library.
The other answer is correct. Just in case the link there gets broken, here's what happened in my case and how I fixed it.
I was running an older kernel, version 3.10, on a system where Qt5 was installed. One of the libraries – namely, libQt5Core.so.5.11.0, has an ELF section .note.ABI-tag, which specifies that the library was compiled for kernel 3.17.0. Presence of this section can be seen via e.g.
objdump -sj .note.ABI-tag /path/to/library.so
And the fact that it's compiled for a newer kernel is revealed by file, with the hard to notice note, "for GNU/Linux 3.17.0", near the end of its output. In my case it was:
/opt/qt511/lib/libQt5Core.so.5.11.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.17.0, BuildID[sha1]=df5f7e933899d1ff629145ab7ca35b2f9bc41843, stripped
So the fix in my case was to run
strip --remove-section=.note.ABI-tag /path/to/library.so
which removed this section and allowed the library to load.
Beware though, that if you do this, you explicitly break the assumptions the library build system may have used, so things may break. In my case they didn't, though.
Trying to get GtkAda to work. Didn't compile the lib myself, had a lot of problems and finally I found a precompiled library on the internet. Of course GPS didn't find it even after adding it to my path...
So I added it manually to my project and GPS began the compilation. It is just a simple example to see if everything works. Just beginning to learn programming.
WITH Gtk.Main ;
USE Gtk.Main ;
WITH Gtk.Window ;
USE Gtk.Window ;
WITH Gtk.Enums ;
USE Gtk.Enums ;
PROCEDURE MaFenetre IS
win : Gtk_window ;
BEGIN
Init ;
Gtk_New(win,Window_Popup) ;
win.show ;
Main ;
END MaFenetre ;
Which gave me this error:
gnatlink /Users/laurentlutgen/GPS/mafenetre.ali -o
/Users/laurentlutgen/GPS/mafenetre
Undefined symbols for architecture x86_64:
"_ada_c_enum_value_size", referenced from:
.
.
.
"_pango_tab_array_new", referenced from:
pango_tabs__pango_new in pango-tabs.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit
status gnatlink: error when calling /usr/local/gnat/bin/gcc
gnatmake: * link failed.
[2013-08-01 21:16:46] process exited with
status 4 (elapsed time: 09.38s)
The list of files the compiler complains about is quite long so.
Anyone an idea how to solve this.
I use the last version of gnat (2013) from AdaCore for MacOS X. I use MacOS 10.8.
The GtkAda library is xadalib 2012.
Thanks
Laurent
From what I see, gnatlink does not get passed the libraries needed to link against. You said that you added GtkAda to your project manually. By doing this, you probably missed all the linker options specified in the *.gpr file of GtkAda, so your binary does not get linked against the GTK+ library.
I suggest you try to get GPS to find the installed GtkAda project file. You can do this by setting ADA_PROJECT_PATH before launching GPS. If GtkAda is located in GNAT GPL's default path, it looks like this:
$ export ADA_PROJECT_PATH="/usr/local/gnat/lib/gnat"
$ gps
You said you're using a precompiled binary you found on the internet. Are you aware that GtkAda is bundled with the GNAT GPL compiler? You should use that, unless you want to use gtk-quartz as backend (which doesn't require X11). If that's the case, you may find the instructions I wrote for compiling GPS with gtk-quartz helpful (as Simon already noted).
If you want, you can try my GPS port to OSX. By default, it is able to load the *.gpr files bundled with GNAT GPL. On the Usage page, you find instructions of how to change the ADA_PROJECT_PATH if you installed your GNAT somewhere else.
For further help, you should post the *.gpr file of your project.
Edit:
I stand corrected: GtkAda is in fact not included in the GNAT GPL distribution for whatever reason. As XmlAda is included as project to link against, I was sure GtkAda was too, but it isn't; so using XAdaLib seems to be the easiest option. You have to point ADA_PROJECT_PATH to the installation directory of XAdaLib instead of the usual GNAT one to be able to use GtkAda.
As far as I know none of the GPL'ed GNATs from AdaCore for x86 have the capability to generate 64-bit code. I think I read something to that effect somewhere but cannot remember where.
The issue also came up in the Ada-port of Doom3, so if you can find him he might know for sure.
Good day, i build my Qt project with Cmake build system on windows platform, but if i add line in cmake file: add_definitions("-DUNICODE -D_UNICODE") definition of UNICODE not working(MINGW), this work properly only if i build my project with MSVC compiler. After some times i found workaround How do I define a variable when I call CMake, so that qtcreator knows it is defined?, this solution work but if i use native WINAPI functions such as CreateFile i get the compile error, because compiler chose CreateFileA but i use w_char and i would like to use CreateFileW, this is because the definition of macro UNICODE appears before than i include my confugure file.How can i define UNICODE macro in cmakefile?
Have you tried (note the lack of quotes):
add_definitions(-DUNICODE -D_UNICODE)
I want to compile a program using the standard ./configure , make, make install.
I am using 64 bits machine but I want the executable to be 32 bits executable.
What is the way to do this, I did ./configure --help but saw nothing on this (it has the --disable-64bit but it does not seem to do the work
What is the platform and compiler?
I'd be inclined to say either:
run configure to get your Makefile and then add then relevant compiler option to the CFLAGS macro, e.g. CFLAGS=${CFLAGS} -m32 for Sun cc, or
add that macro edit to the Makefile.in file being used as a template by configure.
Edit:
Forgot to add that I've done both several times before when I needed to.