I'm trying to use this lib to connect to a SQLite database, but I'm not even getting compile it together with my simple source code, I get many compilation errors, the compiler fails to compile, so I wonder if can someone help me showing how I configure and compile this project in windows ....
The link of ado-ada project: https://code.google.com/p/ada-ado/
Btw, have a another good way to connect to a MSSQL or SQLite or MySql database ?
C:\Users\AlexB\Desktop\testeSqlIte>gnatmake -P default.gpr
gcc -c -g -O2 -I- -gnatA C:\Users\AlexB\Desktop\ada-ado-0.4.0\src\ado-queries-lo
aders.adb
ado-queries-loaders.adb:25:06: "ADO.STATEMENTS (spec)" depends on "ADO.SCHEMAS (
spec)"
ado-queries-loaders.adb:25:06: "ADO.SCHEMAS (spec)" depends on "UTIL (spec)"
ado-queries-loaders.adb:25:06: "ADO.OBJECTS (spec)" depends on "UTIL (spec)"
ado-queries-loaders.adb:25:06: "ADO.DRIVERS.CONNECTIONS (spec)" depends on "ADO.
STATEMENTS (spec)"
ado-queries-loaders.adb:25:06: "ADO.STATEMENTS (spec)" depends on "ADO.OBJECTS (
spec)"
ado-queries-loaders.adb:25:06: "ADO.OBJECTS (spec)" depends on "ADO.SESSIONS (sp
ec)"
ado-queries-loaders.adb:25:06: "ADO.SESSIONS (spec)" depends on "UTIL (spec)"
ado-queries-loaders.adb:25:06: file "util.ads" not found
ado-queries-loaders.adb:25:06: "ADO.QUERIES.LOADERS (body)" depends on "ADO.DRIV
ERS.CONNECTIONS (spec)"
ado-queries-loaders.adb:25:06: "ADO.DRIVERS.CONNECTIONS (spec)" depends on "UTIL
(spec)"
ado-queries-loaders.adb:27:06: file "util.ads" not found
ado-queries-loaders.adb:28:06: file "util.ads" not found
ado-queries-loaders.adb:29:06: file "util.ads" not found
ado-queries-loaders.adb:30:06: file "util.ads" not found
ado-queries-loaders.adb:31:06: file "util.ads" not found
ado-queries-loaders.ads:19:20: "ADO.QUERIES (spec)" depends on "ADO (spec)"
ado-queries-loaders.ads:19:20: "ADO (spec)" depends on "UTIL (spec)"
ado-queries-loaders.ads:19:20: file "util.ads" not found
ado-queries-loaders.ads:19:20: "ADO.QUERIES (spec)" depends on "UTIL (spec)"
ado-queries-loaders.ads:19:20: "ADO.SQL (spec)" depends on "UTIL (spec)"
ado-queries-loaders.ads:19:20: "ADO.PARAMETERS (spec)" depends on "ADO.DRIVERS (
spec)"
ado-queries-loaders.ads:19:20: "ADO.DRIVERS (spec)" depends on "UTIL (spec)"
ado-queries-loaders.ads:19:20: "ADO.QUERIES.LOADERS (body)" depends on "ADO.QUER
IES.LOADERS (spec)"
ado-queries-loaders.ads:19:20: "ADO.QUERIES.LOADERS (spec)" depends on "ADO.QUER
IES (spec)"
ado-queries-loaders.ads:19:20: "ADO.QUERIES (spec)" depends on "ADO.SQL (spec)"
ado-queries-loaders.ads:19:20: "ADO.SQL (spec)" depends on "ADO.PARAMETERS (spec
)"
ado-queries-loaders.ads:19:20: "ADO.PARAMETERS (spec)" depends on "ADO.DRIVERS.D
IALECTS (spec)"
ado-queries-loaders.ads:19:20: "ADO.DRIVERS.DIALECTS (spec)" depends on "UTIL (s
pec)"
gnatmake: "C:\Users\AlexB\Desktop\ada-ado-0.4.0\src\ado-queries-loaders.adb" com
pilation error
The project’s home page (which you link to) says that it requires Ada Util Library and Dynamo. You will need to install them (your error listings show that you definitely need Ada Util, I don’t know about Dynamo).
You ask for Windows build help: do you have a Unix-like environment installed (eg Cygwin)? If so, you can attempt to set up using the supplied configure and then make in the ’standard’ Unix way, but if not your best bet is to copy the supplied .gpr.in files to the corresponding .gpr and edit to remove the % variables using your intuition: for example, ado.gpr.in starts with
with "config";
with "#UTIL_DIR#util";
project Ado is
Version := "#ADO_VERSION#";
Library_Dir := "#ADO_LIBDIR#";
and #UTIL_DIR# needs to be replaced with the directory where util.gpr is to be found; then,
gnatmake -p -P ado
You’ll need a similar approach for Ada Util. As far as I can see, it needs to be configured but it doesn’t need to be built or installed (when configuring ada-ado, you need to add --with-ada-util=/dir/where/ada-util/source/is; the library build looks OK against Ada Util 1.7.0, but I needed the 1.6.1 version to get the tests to build.
Related
I have built and installed mpich from source (mpich-3.4.1.tar.gz), using the steps given in 'https://www.mpich.org/static/downloads/3.4.1/mpich-3.4.1-README.txt'. I want the resultant executables to be dynamically linked to libraries specified in the path '/home/myname/mylibs'. So, before calling ./configure, I have set my LD_LIBRARY_PATH as:
setenv LD_LIBRARY_PATH /home/myname/mylibs:$LD_LIBRARY_PATH
Inside the directory '/home/myname/mylibs' I have soft linked 'libc.so.6' and 'libstdc++.so.6' to my desired libraries, as I do not want the resultant executables to link to dynamic libraries from path /lib64/. I was able to build and install mpich in my machine. However, when I call 'ldd' on one of the executables (hydra_pmi_proxy) that were generated, I see the following:
$ ldd /home/myname/mpich-3.4.1_install/bin/hydra_pmi_proxy
libc.so.6 => /lib64/libc.so.6 (0x00007f32f9eef000)
libstdc++.so.6 => /home/myname/mylibs/libstdc++.so.6 (0x00007f32f9542000)
The rpath seems to be set to my desired path '/home/myname/mylibs' as shown below:
$ readelf -d /home/myname/mpich-3.4.1_install/bin/hydra_pmi_proxy | egrep "RPATH|RUNPATH"
0x000000000000000f (RPATH) Library rpath: [/home/myname/mylibs]
As shown above, libstdc++.so.6 is pointing to my desired library, but libc.so.6 is still pointing to /lib64/libc.so.6. I want libc.so.6 to point to /home/myname/mylibs/libc.so.6
Is there anything I can do to make this possible?
I do not want my exe to be dynamically linked to libraries in /lib64/ because when I launch my MPI program on multiple machines it seems 'hydra_pmi_proxy' is trying to dynamically link to the /lib64/libc.so.6 of the machine on which a certain process is running. (Most likely, it spawns a child process on the new machine which in turn dynamically links to /lib64/libc.so.6 of that machine). I have seen that I am getting an error when one of the mpi processes tries to run on any machine in which /lib64/libc.so.6 is pointing to an older version. The error is:
/home/myname/mpich-3.4.1_install/bin/hydra_pmi_proxy: /lib64/libc.so.6: version `GLIBC_2.17' not found (required by /home/myname/mpich-3.4.1_install/bin/hydra_pmi_proxy).
When I login to this machine, in which it is failing, and do strings /lib64/libc.so.6 | grep GLIBC_2, I do not see GLIBC_2.17 listed. Whereas, on all other machines, on which the mpi processes are running successfully, I see GLIBC_2.17 listed on running 'strings'. So, my intention is to make all executables to dynamically link to only libraries at "/home/myname/mylibs/". Is this the right way?
I do not want the resultant executables to link to dynamic libraries from path /lib64/
libc.so.6 is a special case. See this answer to understand why.
If you really want to isolate your binaries from libraries in /lib64/..., you must:
configure build and install into /home/myname/mylibs/ a new version of GLIBC (symlinking isn't sufficient) and
set your --dynamic-linker and --rpath to point into mylibs.
That said, you didn't explain why you don't want to link libraries from /lib64. http://xyproblem.info might be relevant here.
Trying to build the example code in ada-util. So i'm running
gnatmake json.adb inside the ada-util/samples/ directory.
However I get the following error:
gnatmake json.adb
gcc -c json.adb
json.adb:21:06: file "util.ads" not found
json.adb:23:06: file "util.ads" not found
json.adb:23:06: "Json (body)" depends on "Mapping (spec)"
json.adb:23:06: "Mapping (spec)" depends on "Util (spec)"
json.adb:24:06: file "util.ads" not found
json.adb:25:06: file "util.ads" not found
json.adb:26:06: file "util.ads" not found
gnatmake: "json.adb" compilation error
So there's clearly something wrong with my path because I've installed ada-util and I can confirm that util.ads is in the install directory. Now, clearly there's something going wrong here as this isn't the first PATH issue I've had with Ada recently. Where is it supposed to be installed? As currently it's under /opt/GNAT/2020/include/utilada_core.static/util.ads where the GNAT install lives.
Questions:
Where should it be if not here?
Do I have to tell gnatmake where it is and if so how - couldn't see in the docs
If so, why do I have to tell gnatmake where it is given I followed the install instructions -- is that a bug in the install process or is something else going on?
Looks for me, like the library is in proper place.
As you guess properly, you have to tell it where the library is located. As far I see, in the root directory of the project, there is the file samples.gpr. Thus, if you want to build samples, you have to execute in the root directory of the project:
gnatmake -P samples.gpr
Or, if you are in samples directory (like in your example):
gnatmake -P ../samples.gpr
This should build all samples.
By default, gnatmake can't find needed libraries, same as GCC can't find extra libraries for C/C++ projects. It is generally done by GNAT Project files (these one with .gpr extension, easy way) or via compilation flags (hard way) or Makefiles. The Ada compilation process is similar to the C/C++. It also needs a lot of flags, settings and sometimes, for a bigger project not working out of the box. :)
source code
with Ada.Text_IO;
procedure hello_world is
begin
Ada.Text_IO.Put_line(“Hello World”);
Ada.Text_IO.Put(“by Jeffy Fifa”);
Ada.Text_IO.New_Line;
end hello_world;
enter image description here
Well, as Simon Wright already stated in a comment, ensure that GNAT is installed correctly. You can download the community edition here. Then, after the installation succeeded:
Ensure that C:\GNAT\2018\bin is in the search path:
C:\> echo %PATH%
[...];C:\GNAT\2018\bin;[...]
Ensure that gnatmake executes:
C:\> gnatmake --version
GNATMAKE Community 2018 (20180523-73)
Copyright (C) 1995-2018, Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Switch to the folder where the file hello_world.adb is located, and try to compile the file using:
E:\> gnatmake -g hello_world.adb
gcc -c -g hello_world.adb
gnatbind -x hello_world.ali
gnatlink hello_world.ali -g
still facing some strange compilation error while using MSYS2 mingw64 to compile OpenLDAP
I think it boils down to some win socket thing, currently facing 2 major errors during make depend and make
during make depend
cannot locate nt_err.c in servers/slapd/slapi ==> I resorted to copy nt_err.c from libraries/liblber/nt_err.c
Then came the fatal error while make depend in slapi. Command used by make depend: make -w -I/usr/include -I/usr/include -I/usr/include -I/usr/include depend, it maybe because I have passed -I/usr/include in the main make depend
but still
Entering directory '/home/Jimmy/openldapsrc/openldap-2.4.46/servers/slapd/slapi'
../../../build/mkdep -l -d "." -c "cc" -m "-M" -I../../../include -I.. -I. -I../../../include -I./.. -I. plugin.c slapi_pblock.c slapi_utils.c printmsg.c slapi_ops.c slapi_dn.c slapi_ext.c slapi_overlay.c nt_err.c
In file included from slapi_utils.c:34:0:
../../../include/netdb.h:73:10: fatal error: netinet/in.h: No such file or directory
#include <netinet/in.h>
^~~~~~~~~~~~~~
compilation terminated.
And actually I have seen a lot of similar errors, for example during make it will also give error in slapi like
No such file or directory
#include <sys/socket.h>
^~~~~~~~~~~~~~
compilation terminated.
I have checked with pacman -Fs in.h socket.h the output are as follow
msys/msys2-runtime-devel 2.10.0-2
usr/include/cygwin/in.h
usr/include/netinet/in.h
usr/include/sys/socket.h
and I have msys2-runtime-devel installed. Nonetheless this reminded me that during ./configure output contained
checking sys/socket.h usability... no
checking sys/socket.h presence... no
so Ｉ tried to run gcc -xc -E -v - trying to determine what directory is included, however in MSYS2-MINGW64 it stopped at this
COLLECT_GCC=C:\msys64\mingw64\bin\gcc.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-7.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev1, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 7.3.0 (Rev1, Built by MSYS2 project)
COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/cc1.exe -E -quiet -v -iprefix C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/ -D_REENTRANT - -mtune=generic -march=x86-64
the cc1 gave no output, froze MSYS2 and I have to terminate cc1 from task manager.
Then I run directly C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/cc1.exe -E -quiet -v -iprefix C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/ -D_REENTRANT - -mtune=generic -march=x86-64
it returned
ignoring duplicate directory "C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/7.3.0/include"
ignoring nonexistent directory "C:/building/msys64/mingw64/include"
ignoring nonexistent directory "/mingw64/include"
ignoring duplicate directory "C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64- w64-mingw32/7.3.0/include-fixed"
ignoring duplicate directory "C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "C:/building/msys64/mingw64/x86_64-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/include
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64- mingw32/7.3.0/../../../../include
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/include-fixed
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/include
End of search list.
Turns out the #include <...> search does not include the /usr/include directory of MSYS2, should have been C:/msys64/mingw64/bin/../../usr/include
I tried putting ENV CFLAGS="-I/usr/include" before ./configure, that caused more errors, many .h not usable but presence. and sys/socket.h is usable and presence.
So turns out -I/usr/include somehow did not pass into the compiler?
My Question is, is this configurable? Or is there something wrong with my setup?
OpenLDAP 2.4.46
MSYS2 20161025
MSYS2 has three different toolchains with different purposes:
The msys-2.0.dll-based toolchain, which creates executables that use the POSIX emulation capabilities provided by msys-2.0.dll. The main compiler is /usr/bin/gcc and it uses headers from /usr/include. This is the toolchain to use if your program was written for a Linux or another POSIX-type operating system and you are finding it difficult to port it to Windows because it uses a lot of features not supported by Microsoft.
MinGW 32-bit toolchain. This compiles native Windows software that can run on 32-bit or 64-bit versions of Windows. The main compiler is /mingw32/bin/gcc. To use this toolchain you must launch MSYS2 with the "MinGW-w64 32-bit Shell" shortcut or launch mingw32.exe. This toolchain is not compatible with the headers in /usr/include, but it can use native Windows headers with interfaces defined by Microsoft, like windows.h.
MinGW 64-bit toolchain. This toolchain is just like the 32-bit toolchain except the executables are 64-bit executables, and thus only work on 64-bit Windows. It has its own shortcut in the start menu, and can also be launched with mingw64.exe.
I don't know anything about OpenLDAP, but if it is requiring a bunch of headers that the MinGW toolchains don't have, you could either try to port it to Windows or switch over to building it with the msys-2.0.dll-based toolchain.
My code is:
with Ada.Text_IO; use Ada.Text_IO;
procedure Hello is
begin
Put_Line ("Hello, world!");
end Hello;
GNAT makes a .o and .ali.
I type
gcc hello.o -o hello
GCC complains:
/usr/lib/gcc/i686-linux-gnu/6/../../../i386-linux-gnu/crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
hello.o: In function `_ada_hello':
hello.adb:(.text+0x26): undefined reference to `ada__text_io__put_line__2'
collect2: error: ld returned 1 exit status
You shouldn't try to compile Ada programs by hand with the gcc command. There are two sensible alternatives depending on your preferences:
Use the gnatmake command as Brian suggests in his comment. This works well as long as all the relevant source files are stored in the same directory.
Create a project file and use gprbuild. Projects can handle source files distributed in multiple directories, include other projects, contain compiler and linker flags, etc.
On the "Hello_World" level, gnatmake works okay, but you should be aware that gnatmake doesn't behave like a real Ada compiler, unless you pass it some specific flags. I've managed this with an alias in my shell, but in reality it is yet another argument in favour of using gprbuild even for tiny projects, as you can put the flags which make GCC behave like a real Ada compiler in the project files, and not worry more about it.
project Hello_World is
for Source_Dirs use ("src");
for Object_Dir use "obj";
for Exec_Dir use "bin";
for Main use ("hello.adb");
package Builder is
for Default_Switches ("Ada")
use ("-m");
end Builder;
package Compiler is
for Default_Switches ("Ada")
use ("-fstack-check", -- Generate stack checking code (part of Ada)
"-gnata", -- Enable assertions (part of Ada)
"-gnato13", -- Overflow checking (part of Ada)
"-gnatf", -- Full, verbose error messages
"-gnatwa", -- All optional warnings
"-gnatVa", -- All validity checks
"-gnaty3abcdefhiklmnoOprstux", -- Style checks
"-gnatwe", -- Treat warnings as errors
"-gnat2012", -- Use Ada 2012
"-Wall", -- All GCC warnings
"-O2"); -- Optimise (level 2/3)
end Compiler;
end Hello_World;
If you use GNAT Programming Studio (GPS) as your IDE, you may want to remove the -gnatf flag, as I have experienced that can prevent GPS from parsing the error messages from the compiler.