running PostgreSQL client in C from Cygwin - postgresql

I'm trying to build a very simple PostgreSQL client in C over Cygwin.
Here's what I've done so far:
I've downloaded the PostgreSQL source code version 9.1.2 (to match the same version that is running on my server)
I've configured and compiled the source code from Cygwin. The compilation seemed to go smoothly.
From what I can tell, the header files are in:
/cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq, and
/cygdrive/c/workspace/src/postgresql-9.1.2/src/include
The libraries are in:
/cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq
From here, I compiled and linked the client program using the makefile below:
testlibpq: testlibpq.c
gcc -o testlibpq -I /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq -I /cygdrive/c/workspace/src/postgresql-9.1.2/src/include -L /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq testlibpq.c -Bstatic -lpq
The compilation and the linking succeeded without errors or warnings.
However, when I try to run the program, I get the following error:
$ ./testlibpq
/cygdrive/c/Users/dleclair/Dropbox/denis/src/testlibpq/testlibpq.exe: error while loading shared libraries: cygpq.dll: cannot open shared object file: No such file or directory
I haven't figured out how to fix this. Any pointers would be greatly appreciated.
Oh, one more thing, I found the folder that cygpq.dll was sitting in and set my LD_LIBRARY_PATH to point to it but it still gave me the same result.
dleclair#dleclair-win7l ~/Dropbox/denis/src/testlibpq
$ ls /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq
bcc32.mak encnames.o fe-connect.o fe-misc.o fe-protocol3.o ip.o libpq-events.c md5.c pgstrcasecmp.c pqsignal.c thread.o
blibpqdll.def exports.txt fe-exec.c fe-print.c fe-secure.c libpq.a libpq-events.h md5.o pgstrcasecmp.o pqsignal.h wchar.c
chklocale.c fe-auth.c fe-exec.o fe-print.o fe-secure.o libpq.rc.in libpq-events.o nls.mk po pqsignal.o wchar.o
chklocale.o fe-auth.h fe-lobj.c fe-protocol2.c inet_net_ntop.c libpqddll.def libpq-fe.h noblock.c pqexpbuffer.c pthread-win32.c win32.c
cygpq.dll fe-auth.o fe-lobj.o fe-protocol2.o inet_net_ntop.o libpq-dist.rc libpq-int.h noblock.o pqexpbuffer.h README win32.h
encnames.c fe-connect.c fe-misc.c fe-protocol3.c ip.c libpqdll.def Makefile pg_service.conf.sample pqexpbuffer.o thread.c win32.mak
dleclair#dleclair-win7l ~/Dropbox/denis/src/testlibpq
$ echo $LD_LIBRARY_PATH
/cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq
dleclair#dleclair-win7l ~/Dropbox/denis/src/testlibpq

Normally on unix/linux systems after building the source a make install is done which copies the headers to standard locations like /usr/local/include and /usr/local/lib. You may have to do that on cygwin to to get the DLL in the search path.
Or you can just locate the DLL yourself and put it on the search path or in the same folder as your executable.

Related

Error with static compilation Qt with postgresql driver

I have installed through Mainteinance Tool Qt 5.12.5 and the sources. I have the next directories:
C:\Qt\5.12.5\Src
C:\Qt\Tools\mingw730_32\
C:\Qt\Tools\mingw730_64\
On the other hand, I have read that downloable Postgres version is compiled with MSVC, and I must to compile my own version. I have do it following link, and now I have a postgresql version in c:\pgsql
Finally I have added c:\pgsql to user Path
Next step, I have opened PowerShell in Admin mode and I´ve gone to C:\Qt\5.12.5\Src\.
Next, set the env path for this PowerShell session:
$env:Path += ";C:\Qt\Tools\mingw730_64\bin\;C:\Qt\5.12.5\Src;C:\pgsql\include\;C:\pgsql\lib\;C:\pgsql\bin\" (setting the pgsql path again....)
After that, I execute configure.bat like that:
configure -v -static -release -static-runtime -platform win32-g++ -prefix C:\Qt\5.12.5\Estatico\ -opensource -confirm-license -qt-zlib -qt-pcre -qt-libpng -qt-libjpeg -qt-freetype -opengl desktop -no-openssl -opensource -confirm-license -skip webengine -make libs -nomake tools -nomake examples -nomake tests -sql-psql
But I have get this error:
ERROR: Feature 'sql-psql' was enabled, but the pre-condition 'libs.psql' failed.
Searching in config.log I can read those lines:
loaded result for library config.qtbase_sqldrivers.libraries.psql
Trying source 0 (type pkgConfig) of library psql ...
pkg-config use disabled globally.
=> source produced no result.
Trying source 1 (type psqlConfig) of library psql ...
pg_config not found.
=> source produced no result.
Trying source 2 (type psqlEnv) of library psql ...
None of [liblibpq.dll.a liblibpq.a libpq.dll.a libpq.a libpq.lib] found in [] and global paths.
=> source produced no result.
Trying source 3 (type psqlEnv) of library psql ...
=> source failed condition '!config.win32'.
test config.qtbase_sqldrivers.libraries.psql FAILED
What can I do or what is the properly way to do that?
Thank you in advance.
UPDATE
There are similar question here but it hasn´t been solved, and those question ask about Visual Studio.
I want to compile it under mingw.
The solution suggested by #Soheil Armin doesn´t work too
The solution suggested by #Soheil Armin works fine, but I need to delete the entire source tree and reinstall it as he suggested. If not, a new configure won't work.
Also, the ^ character can be saved:
configure <your parameters>
PSQL_LIBS="C:\pgsql\lib\libpq.a"
-I "C:\pgsql\include"
-L "C:\pgsql\lib"
You need to explicitly define library paths of Postgres.
configure <your parameters> ^
PSQL_LIBS="C:\pgsql\lib\libpq.a" ^
-I "C:\pgsql\include" ^
-L "C:\pgsql\lib"

How can I get "HelloWorld - BitBake Style" working on a newer version of Yocto?

In the book "Embedded Linux Systems with the Yocto Project", Chapter 4 contains a sample called "HelloWorld - BitBake style". I encountered a bunch of problems trying to get the old example working against the "Sumo" release 2.5.
If you're like me, the first error you encountered following the book's instructions was that you copied across bitbake.conf and got:
ERROR: ParseError at /tmp/bbhello/conf/bitbake.conf:749: Could not include required file conf/abi_version.conf
And after copying over abi_version.conf as well, you kept finding more and more cross-connected files that needed to be moved, and then some relative-path errors after that... Is there a better way?
Here's a series of steps which can allow you to bitbake nano based on the book's instructions.
Unless otherwise specified, these samples and instructions are all based on the online copy of the book's code-samples. While convenient for copy-pasting, the online resource is not totally consistent with the printed copy, and contains at least one extra bug.
Initial workspace setup
This guide assumes that you're working with Yocto release 2.5 ("sumo"), installed into /tmp/poky, and that the build environment will go into /tmp/bbhello. If you don't the Poky tools+libraries already, the easiest way is to clone it with:
$ git clone -b sumo git://git.yoctoproject.org/poky.git /tmp/poky
Then you can initialize the workspace with:
$ source /tmp/poky/oe-init-build-env /tmp/bbhello/
If you start a new terminal window, you'll need to repeat the previous command which will get get your shell environment set up again, but it should not replace any of the files created inside the workspace from the first time.
Wiring up the defaults
The oe-init-build-env script should have just created these files for you:
bbhello/conf/local.conf
bbhello/conf/templateconf.cfg
bbhello/conf/bblayers.conf
Keep these, they supersede some of the book-instructions, meaning that you should not create or have the files:
bbhello/classes/base.bbclass
bbhello/conf/bitbake.conf
Similarly, do not overwrite bbhello/conf/bblayers.conf with the book's sample. Instead, edit it to add a single line pointing to your own meta-hello folder, ex:
BBLAYERS ?= " \
${TOPDIR}/meta-hello \
/tmp/poky/meta \
/tmp/poky/meta-poky \
/tmp/poky/meta-yocto-bsp \
"
Creating the layer and recipe
Go ahead and create the following files from the book-samples:
meta-hello/conf/layer.conf
meta-hello/recipes-editor/nano/nano.bb
We'll edit these files gradually as we hit errors.
Can't find recipe error
The error:
ERROR: BBFILE_PATTERN_hello not defined
It is caused by the book-website's bbhello/meta-hello/conf/layer.conf being internally inconsistent. It uses the collection-name "hello" but on the next two lines uses _test suffixes. Just change them to _hello to match:
# Set layer search pattern and priority
BBFILE_COLLECTIONS += "hello"
BBFILE_PATTERN_hello := "^${LAYERDIR}/"
BBFILE_PRIORITY_hello = "5"
Interestingly, this error is not present in the printed copy of the book.
No license error
The error:
ERROR: /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb: This recipe does not have the LICENSE field set (nano)
ERROR: Failed to parse recipe: /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb
Can be fixed by adding a license setting with one of the values that bitbake recognizes. In this case, add a line onto nano.bb of:
LICENSE="GPLv3"
Recipe parse error
ERROR: ExpansionError during parsing /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb
[...]
bb.data_smart.ExpansionError: Failure expanding variable PV_MAJOR, expression was ${#bb.data.getVar('PV',d,1).split('.')[0]} which triggered exception AttributeError: module 'bb.data' has no attribute 'getVar'
This is fixed by updating the special python commands being used in the recipe, because #bb.data was deprecated and is now removed. Instead, replace it with #d, ex:
PV_MAJOR = "${#d.getVar('PV',d,1).split('.')[0]}"
PV_MINOR = "${#d.getVar('PV',d,1).split('.')[1]}"
License checksum failure
ERROR: nano-2.2.6-r0 do_populate_lic: QA Issue: nano: Recipe file fetches files and does not have license file information (LIC_FILES_CHKSUM) [license-checksum]
This can be fixed by adding a directive to the recipe telling it what license-info-containing file to grab, and what checksum we expect it to have.
We can follow the way the recipe generates the SRC_URI, and modify it slightly to point at the COPYING file in the same web-directory. Add this line to nano.bb:
LIC_FILES_CHKSUM = "${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949"
The MD5 checksum in this case came from manually downloading and inspecting the matching file.
Done!
Now bitbake nano ought to work, and when it is complete you should see it built nano:
/tmp/bbhello $ find ./tmp/deploy/ -name "*nano*.rpm*"
./tmp/deploy/rpm/i586/nano-dbg-2.2.6-r0.i586.rpm
./tmp/deploy/rpm/i586/nano-dev-2.2.6-r0.i586.rpm
I have recently worked on that hands-on hello world project. As far as I am concerned, I think that the source code in the book contains some bugs. Below there is a list of suggested fixes:
Inheriting native class
In fact, when you build with bitbake that you got from poky, it builds only for the target, unless you mention in your recipe that you are building for the host machine (native). You can do the latter by adding this line at the end of your recipe:
inherit native
Adding license information
It is worth mentioning that the variable LICENSE is important to be set in any recipe, otherwise bitbake rises an error. In our case, we try to build the version 2.2.6 of the nano editor, its current license is GPLv3, hence it should be mentioned as follow:
LICENSE = "GPLv3"
Using os.system calls
As the book states, you cannot dereference metadata directly from a python function. Which means it is mandatory to access metadata through the d dictionary. Bellow, there is a suggestion for the do_unpack python function, you can use its concept to code the next tasks (do_configure, do_compile):
python do_unpack() {
workdir = d.getVar("WORKDIR", True)
dl_dir = d.getVar("DL_DIR", True)
p = d.getVar("P", True)
tarball_name = os.path.join(dl_dir, p+".tar.gz")
bb.plain("Unpacking tarball")
os.system("tar -x -C " + workdir + " -f " + tarball_name)
bb.plain("tarball unpacked successfully")
}
Launching the nano editor
After successfully building your nano editor package, you can find your nano executable in the following directory in case you are using Ubuntu (arch x86_64):
./tmp/work/x86_64-linux/nano/2.2.6-r0/src/nano
Should you have any comments or questions, Don't hesitate !

What is the greylist.txt in a kmod rpm package

Many device driver appear as a kmod-<drivername> rpm package in CentOS/RHEL, and there is always a greylist.txt in these package, with some kernel symbol as its contents. Here are an example:
[root#localhost download]# rpm -ql kmod-qed
/etc/depmod.d/qed.conf
/lib/modules/3.10.0-327.36.2.el7.x86_64
/lib/modules/3.10.0-327.36.2.el7.x86_64/extra
/lib/modules/3.10.0-327.36.2.el7.x86_64/extra/qed
/lib/modules/3.10.0-327.36.2.el7.x86_64/extra/qed/qed.ko
/usr/share/doc/kmod-qed/greylist.txt
[root#localhost download]# cat /usr/share/doc/kmod-qed/greylist.txt
bitmap_clear
bitmap_set
__fentry__
ioremap_wc
pci_enable_msi_range
pci_enable_msix_range
pci_ioremap_bar
pci_is_pcie
pci_read_config_byte
pci_read_config_word
pci_save_state
release_firmware
request_firmware
__smp_mb__after_atomic
__stack_chk_fail
synchronize_irq
tasklet_init
__tasklet_schedule
vzalloc
x86_dma_fallback_dev
zlib_inflate
zlib_inflateEnd
zlib_inflateInit2
zlib_inflate_workspacesize
I guess it must have something to do with the kernel ABI whitelist, but what exactly is the purpose of this greylist file? and how was it generated while packaging the kmod rpm.
Thanks.
In the absence of a better answer I can tell you that since it is under /usr/share/doc it should just be documentation and nothing of consequence. I wish I could tell you the purpose and how it was generated. I can only see that it was not generated during packaging. You can see in the Spec file that it is included as a static source. (Grab the SRPM and have a look.)

Postgis Extension install PostgreSQL

When I try to enable PostGis extension on my database I receive the following:
postgis=# CREATE EXTENSION postgis;
ERROR: could not load library "/usr/pgsql-9.3/lib/rtpostgis-2.1.so": libhdf5.so.6: cannot open shared object file: No such file or directory
I used find -name to find the files:
[root#digihaul3-pc /]# find -name rtpostgis-2.1.so
./usr/pgsql-9.3/lib/rtpostgis-2.1.so
[root#digihaul3-pc /]# find -name libhdf5.so.6
./usr/lib64/mpich2/lib/libhdf5.so.6
./usr/pgsql-9.3/lib/libhdf5.so.6
./usr/lib/mpich2/lib/libhdf5.so.6
Credit to Thinking Monkey # on this post
it is for fordora 15. But i tried everything else and this actually fixed my issue and allowed me to install the postgis extentions. Doesn't take long to install.
Thinking Monkeys Post:
Checked for whether /etc/ld.so.conf has a reference to the path /usr/lib64/mpich2/lib.
by doing ldconfig -p | grep libhdf5.
Which did not output anything.
On checking that /etc/ld.so.conf had include ld.so.conf.d/*.conf.
Checked for the files in directory ld.so.conf.d. One of the conf file in include ld.so.conf.d was /etc/ld.so.conf.d/atlas-x8664.conf which contained /usr/lib64/atlas.
So I,
created a file called gdal.conf in the directory ld.so.conf.d.
Added the string /usr/lib64/mpich2/lib to the file.
Ran ldconfig.
Now, ldconfig -p | grep libhdf5 had the paths to llibhdf5 files.
After doing the above, postgis raster support installation went smoothly.

fuseki load graph - s-put not found

I am trying to load a graph in fuseki. The server is working as it should.
But when I try s-put inside the fuseki folder it tells me s-put is not found?!
hdeus$ ls
DEPENDENCIES config.ttl s-delete
Data fuseki s-get
LICENSE fuseki-server s-head
NOTICE fuseki-server.bat s-post
ReleaseNotes.txt fuseki-server.jar s-put
config-examples.ttl fuseki_config.ttl s-query
config-inf-tdb.ttl log4j.properties s-update
config-tdb.ttl pages s-update-form
hdeus$ sudo ./s-put http://localhost:3030/ds/data default Data/books.ttl
sudo: ./s-put: command not found
Any idea what the problem might be? I tried copy/paste s-put from the ls output but stil nothing... I am working in mac os X
Is the file executable? If you unpacked from the zip file, you need to set the s-* executable. Also, you need ruby installed.