Well, this is our bad, sorry for that. This relies on the Connector/C code that hasn't been released yet, and to workaround the problem and to be able to build from source you need to checkout Connector/C from git repository(https://github.com/MariaDB/mariadb-connector-c/), and build it from source as well.
So, the issue will be solved as soon as next C/C release is out. I will close the issue then
We actually plan to make C/C as a subproject, and in this way C/C git checkout and build from source will be done automatically.
I am not sure if that works for everybody, but it will solve issues like this. But I guess we will live opportunity to build it "old style" as well.
You do plan to make C/C as a subproject?
I don't find it as a good solution. Let me explain:
You distribute your software as parts (server, C/C, C/ODBC and their versions). If you build some part and distribute it, everything's okay. Until some maintainer comes to you and wants to add you software to his OS. At that point, you have pretty nicely versioned pieces of software, but every and each one of them was build with different versions of other software, even unreleased. Your C/C won't match your server developement any more. You have C/C, but it does not make sense, since you never use any released version of it.
At the same time you have server with different library than C/C, you fix something in server, but C/C will wait months to get that fix released.
Release system like that one use tiny projects that does not actually release anything, they just expect people to always build their software from the latest git commit.
Ideally, I look forward an exact opposite:
Server, that has to rely on specific C/C version. You would have stable both backward and forward compatibile API, which can be relied on.
The C/C could actually contain whole client - which is mostly state user wants to get - divided clent and server. Clients that chnages very little and can connect to both older and newer servers, becasuse of the stable API. An user won't need to build everything in order to get the client part. (Now, you have to build server for several hours and then throw nearly everything away, if you want only a client ).
Your binaries - each of them - contains bundled libraries, which makes them 10x-100x bigger (PostgreSQL is a nice example, where client binaries has only few kilobytes and link dynamically.) Than right question emerge - is there any point in dynamic linking, if you won't have any stable releases and parts depending on each other as standalone projects (instead of enormous chunk called 'server', that actually does everything).
–
Don't get this anyhow offensive. I'd totally like to open another ticket for this topic and discuss this with other OSs maintainers.
In short:
IMHO, if you want to use C/C as a git submodule everywhere, there's no point in releasing it anyway, since everything would bundle it.
IMHO, separated client, server and connectors (as much as standalone project) would definitelly lead to stable API, instead of a big mystery (because every release would origin from different commits of bundled stuff) changing with every release of anything (because you can, once you use it as a git submodule)
What are your opinions about MariaDB evolution, that could be brought by separating or bundling C/C to / from everything?
I'm wondering how this git-approach will work in practice. Are you going to tag a specific mariadb-connect-c commit for each odbc release/commit or going to rely on a branch? (which would make builds unreproducable?)
Sorry, short answer so far.
No, we want to link releases only against C/C releases, and thus we plan to use C/C release tags for builds with git subproject. We don't want things like in this report to happen any more
Could you link to specific commit hashes? Tags can be moved, which could be an issue for people who want to ensure reproducable builds. Commits can still be deleted, but then at least you know what happened.
A git submodule would probably be an ideal match for this use case.
Novitsky said: "want to link releases only against C/C releases"
For example C/C repo:
|
commit A
|
commit B
|
commit C <-- release C/C 3.0.0
|
commit D
|
commit E
|
commit F
|
commit G <-- release C/C 3.0.1
|
commit H
|
commit I
|
And you will only link releases against released C/C, which means only against commit C or G.
In such a case, it makes sense to me.
The requirements from my side would be only to have:
1) linked released C/C available
2) information against which C/C release is your build (of server or C/ODBC ) composed.
Do I get it right?
unilynx : Yes, it's possible to link against specific commit.
But we don't move release tags. They are part of the procedure, and specifically put in place to mark what the release was built from. But I think even if we checkout a tag in the submodule, parent project's log will say that the commit in the submodule is changed from one hash to the new one. I mean, it will record commit, not the tag.
mschorm You get it right. That is the plan. It's time to do things right.
I actually have the branch with C/C as subproject for quite a while. And I did not merge it, since I expected this your reaction 
- I guessed that linux distribution package maintainers would be unhappy. But looks like you are fine about that (with some prerequisites). I also considered to add option to build it old way. i.e., with some option specified, cmake will look for c/c headers and library in the way it currently does. do you think that would be good to have? I would prefer to keep things simple, and with submodule they are simple
Hey, Lawrin, you just did it again?
Released MariaDB server 10.2.10 with fixes for CONC/C, but no CONC/C release in sight.
In Fedora, I no longer pack client library from the "mariadb" package, but from CONC/C instead. (Same for other files from C/C, like 'mariadb_config' to which a fix was made recently ...)
—
That's why I'm so sceptic about using C/C as Git submodule. I belive in your intensions, but not the tool you picked for it.
—
In previous replies, what I wanted to say, is:
If a release contains any chnage in C/C, the C/C release with this change should released at the same time or sooner.
EDIT:
There may be one alternativ: if I would be 100% sure, the C/C will be alway forward compatibile. (Or atleast having a table which versions of C/C are compatibile with which range of versions of the server)
I will discuss this incident with interested parties, was it intended or not. But I guess most of people are off today.
There was agreement that c/odbc and c/c releases should be aligned (just in the way you described it). And I still think, that submodule can work for that. Not sure if the same thing was discussed/decided about server releases. It may be actually different with the server, relationships between server and client lib are a bit different, as between c/odbc and c/c. For example server source package includes c/c sources. But that is only my speculations.
At the end, a table of backwards and forwards compatibility would be handy, because the latest mariadb 10.2.10, may include updated C/C, but it may not affect compatibility.
One way or another, commits like this are too hard for me to check. (If that would affect compatibility)
mschorm, while I generally agree with that, and I agree that this commit is impossible to check, I think it does not matter in your particular case.
Unlike many other distributions, you don't use C/C from MariaDB 10.2, you build C/C separately from C/C sources. So that commit (which only updates what C/C version will be used when compiling MariaDB server) should not affect you.
It does affect others, and we'll need to solve this issue (impossible to check) somehow.
But your case just looks a little bit easier in this regard
I obtain the same error as below.
I am using release 3.0.5, is this fixed in some other release?
ome/mariadb-connector-odbc/ma_bulk.c: In function 'MADB_MapIndicatorValue':
/home/mariadb-connector-odbc/ma_bulk.c:33:34: error: 'STMT_INDICATOR_IGNORE_ROW' undeclared (first use in this function)
case SQL_PARAM_IGNORE: return STMT_INDICATOR_IGNORE_ROW;
^
/home/mariadb-connector-odbc/ma_bulk.c:33:34: note: each undeclared identifier is reported only once for each function it appears in
CMakeFiles/maodbc.dir/build.make:494: recipe for target 'CMakeFiles/maodbc.dir/ma_bulk.c.o' failed
make[2]: *** [CMakeFiles/maodbc.dir/ma_bulk.c.o] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/maodbc.dir/all' failed
make[1]: *** [CMakeFiles/maodbc.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2
chandranana_naik, alas you need to build Connector/C from sources. Latest checkout will work. You need to do something like:
git clone -b master --depth 1 "https://github.com/MariaDB/mariadb-connector-c.git" build
cd build
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DWITH_OPENSSL=ON
make
sudo make install
cd ..
rm build -rf
With next Connector/C 3.0 release with problem will be eliminated. Sorry for inconveniences.
Since C/C 3.0.4 has been already released, I am closing this one