Compiling and using apr_dbd_sqlite3

[Sam Carleton <sc...@miltonstreet.com>]

I have an Apache Module that needs to start using the apr_dbd.  Step one is
going to be to compile the apr_dbd_sqlite3.c to use a custom version of the
sqlite engine.  The question is: how...

I am on Windows using Visual Studio 2008 and Apache 2.2.11.  I have not and
would prefer not to compile Apache.

Do I need to compile the whole apr library, per the instructions on the web
site or should I be able to simply convert the apr_dbd_sqlite3.dsp project
to a Visual Studio 2008 project and compile it?  I did try this and there is
an error about no apu.h file, should I simply copy apu.hw over to apu.h or
is there some pre build process I should run?

Once I get the module compiled, where exactly does mod_dbd go looking for
the apr_dbd_sqlite3?  Does it simply look in the system path or does it look
in a specific location?

Sam

Re: Compiling and using apr_dbd_sqlite3

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On 7/5/2010 8:04 AM, Sam Carleton wrote:
> 
> Thank you very much for the enlightenment.  Considering my use of Apache
> is in a custom app where all my code is in either an Apache Module or
> Axis2/C service, I tend to forget about the bigger picture like those
> using PHP, Perl and such.  Again, I do appreciate all your time to read
> and reply, this has been very enlightening!

You [and many folks here] might be also interested in this project;

  http://coapp.org/

which is effectively seeking to offer a highly-normalized, optimized win32
'distribution' of many OSS packages, starting at the LAMP stack but certainly
not bounded by that.

Re: Compiling and using apr_dbd_sqlite3

[Sam Carleton <sc...@miltonstreet.com>]

On Sun, Jul 4, 2010 at 11:49 PM, William A. Rowe Jr. <wr...@rowe-clan.net>wrote:

> I'll limit my reply to speak to the actual issues, rather than the rest of
> the
> silliness in your rant.
>

Oh, I guess my last email wasn't all that clear:  I am looking for answers
to the "actual issues", yes I ranted initially, but then I was frustrated
and acting less then professional.  But then I hope this mailing list is
able to understand no one is perfect.  What I am trying to understand is:
Why is Apache 2.2 still using an old compiler.   Slowly but surely, thanks
to your help, I am starting to understand.

I learned a long time ago that I ain't all that smart and when I see very
well established things do something I think is bazar, I should find out WHY
they are doing it, fore there is more then likely a good, no not just good,
but WISE reason for it.  Which is the reason I asked WHY.  Despite me being
in a pissing mode, I still wanted to be let in on the wisdom of why the old
compiler was and is being used.


> The science of binary versioning of a single shared library resource was
> solved a very long time ago, so it's strange this still is not applied
> sensibly for such a critical, common requirement as C language
> applications.
> Somehow, all the rest of the MS OS related teams are held to such a basic
> requirement, so it's just puzzling.
>

Ok, I *THINK* I understand the why, is this correct:

The Apache Foundation wants to keep all the DLL dependencies identical for a
given version (2.2) so that when a new version of 2.2 comes out, folks do
not have to go back and recompile all the other code that runs under it,
like Perl, Python, PHP, and custom modules.  Because Microsoft decided to
change the name of their c runtime library, the Apache Foundation is still
compiled with VC6 to keep this binary compatibility.


> Now there are Strawberry Perl and other alternatives, and now that there
> are
> more solutions today, now that the 'express' flavors include the various
> toolchain components, and the DDK team continues to find ways to provide
> the
> msvcrt.dll functionality, as your link points out.  It becomes a question
> of
> what the best choice is, and you are writing to the wrong list for that
> whole
> discussion.
>

So if I understand what you are say here, folks know about options like what
I found and they are still deciding what to do moving forward.


> But there are reasons the tone of your post falls on deaf ears.
>

This is clearly not true, fore you have been very generous to read and reply
to my posts.  The only thing I ever was hoping to see change was my
understanding of the WHY it is the way it is today.

Thank you very much for the enlightenment.  Considering my use of Apache is
in a custom app where all my code is in either an Apache Module or Axis2/C
service, I tend to forget about the bigger picture like those using PHP,
Perl and such.  Again, I do appreciate all your time to read and reply, this
has been very enlightening!

Sam

Re: Compiling and using apr_dbd_sqlite3

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On 7/4/2010 4:52 PM, Sam Carleton wrote:
> On Sun, Jul 4, 2010 at 1:27 AM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>>
>> On 7/3/2010 8:53 AM, Sam Carleton wrote:
>>>
>>> Why?  why why why?  I simply don't get it
>>
>> Sam, please don't waste your energy venting at APR or any other open
>> source effort, take your issues to MS just as we've all tried.
> 
> So if it is Microsoft stopping you

No Sam, the VC team has done all they can to impede, not to 'stop' open
source projects from offering consistent, interoperable behavior.  I'll
limit my reply to speak to the actual issues, rather than the rest of the
silliness in your rant.

The science of binary versioning of a single shared library resource was
solved a very long time ago, so it's strange this still is not applied
sensibly for such a critical, common requirement as C language applications.
Somehow, all the rest of the MS OS related teams are held to such a basic
requirement, so it's just puzzling.

At the time 2.2 binaries were -first- released, there was not quite an
entirely free solution to building these, and whichever choice of a more
modern compiler was picked would have resulted in lock-in to that flavor.
At that time, Perl and Python from ActiveState were on two different versions,
neither on msvcrt.  The 'lite' (free) flavor of the compiler shipped a crippled
toolchain, with basic tools missing from the collection.  And so, we are stuck/
sticking with the flavor first shipped as 2.2, so that modules which already
interoperate continue to keep doing so, until 2.4 (or even 2.3 betas) ship.

Now there are Strawberry Perl and other alternatives, and now that there are
more solutions today, now that the 'express' flavors include the various
toolchain components, and the DDK team continues to find ways to provide the
msvcrt.dll functionality, as your link points out.  It becomes a question of
what the best choice is, and you are writing to the wrong list for that whole
discussion.

But there are reasons the tone of your post falls on deaf ears.

One, you are on the wrong list.

Second, this is Open Source Code; we welcome you and everyone who likes to
compile it exactly as you like, and we've put no impediments in your way,
even done what we can to deal with different versions of windows, msvc (and
gcc, sun cc etc etc etc).  The binaries are just a convenience, if they are
created at all, they have nothing to do with the development and promulgation
of the Source Code we are providing to the public at no charge, which is our
entire purpose.

Re: Compiling and using apr_dbd_sqlite3

[Sam Carleton <sc...@miltonstreet.com>]

On Sun, Jul 4, 2010 at 1:27 AM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>
> On 7/3/2010 8:53 AM, Sam Carleton wrote:
> >
> > Why?  why why why?  I simply don't get it
>
> Sam, please don't waste your energy venting at APR or any other open
> source effort, take your issues to MS just as we've all tried.

So if it is Microsoft stopping you, it leads me to believe Microsoft
has take some legal action to prevent the Apache Foundation from using
a compiler any newer then VC6.  Is that the case?  With the tidbit of
info you provided me about using the WDK libraries to link EXE/DLL's
using the MSVCRT, I had started to believe it was because the Apache
Foundation did not want to add the dependency of one of the newer
runtimes.

For the record, I found this blog about it.

http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/

I have succeeded in linking sqlite3 to use MSVCRT with VS2008.
Currently I am working on getting Axis2/C to link to the older
runtime.  Then I am going to move on to compile the ARP's sqlite3
driver to use MSVCRT.  So from a technical standpoint, this is most
definitely possible.

Sam

Re: Compiling and using apr_dbd_sqlite3

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On 7/3/2010 8:53 AM, Sam Carleton wrote:
> 
> Why?  why why why?  I simply don't get it

Sam, please don't waste your energy venting at APR or any other open
source effort, take your issues to MS just as we've all tried.

We don't get it either, but it is what it is.

Re: Compiling and using apr_dbd_sqlite3

["William A. Rowe Jr." <wr...@rowe-clan.net>]

An OT reply, since you are asking an httpd question on the -wrong-
list...

On 7/3/2010 8:53 AM, Sam Carleton wrote:
> So why is it still using
> a compiler that is 10-years-old!

Apache httpd seeks to keep binary compatibility, and that rather means
keeping the same low level msvcr dependencies, as well.

Re: Compiling and using apr_dbd_sqlite3

[Sam Carleton <sc...@miltonstreet.com>]

On Sat, Jul 3, 2010 at 3:21 AM, William A. Rowe Jr. <wr...@rowe-clan.net>wrote:

> On 7/2/2010 7:53 PM, Sam Carleton wrote:
> >
> > Do I need to compile the whole apr library, per the instructions on the
> > web site or should I be able to simply convert the apr_dbd_sqlite3.dsp
> > project to a Visual Studio 2008 project and compile it?
>
> Twofold question.  First, db providers should be independently compilable,
> so you are good in that regard.
>
> Second, for every free(), close(), fclose() and other non-Win32 call to the
> C API which corresponds to resource creation from within APR, you may
> expect
> a segfault since these sorts of records are constrained to a single flavor
> of the MSVCR library.  The httpd/apr distributed by the httpd project is
> still built on MSVCRT/VC6.
>

Why?  why why why?  I simply don't get it, the Apache server (and what I
have seen of APR) is some of the best written code I have seen.  I know
there are some truly amazing minds behind it.  So why is it still using a
compiler that is 10-years-old!  What is so outstanding about VC6 over any of
the newer, free version of Visual Studio compiler?  I simply don't
understand it, I am sure there is a reason for it but I simply am not seeing
the logic.


> I understand it's possible to build using the DDK libraries to target the
> same MSVCRT, in which case you should have no problems whatsoever.  If you
> build for a Studio 2008 SQLite/apr_dbd_sqlite module, then there may be
> issues if sqlite allocates memory, etc, under the assumption that the
> caller
> will then free those resources, and similarly the whole dbd interface.
>

Off and learn how to get VS2008 to compile against the same ancient runtime
that Apache is using.

Sam

Re: Compiling and using apr_dbd_sqlite3

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On 7/2/2010 7:53 PM, Sam Carleton wrote:
> 
> Do I need to compile the whole apr library, per the instructions on the
> web site or should I be able to simply convert the apr_dbd_sqlite3.dsp
> project to a Visual Studio 2008 project and compile it?

Twofold question.  First, db providers should be independently compilable,
so you are good in that regard.

Second, for every free(), close(), fclose() and other non-Win32 call to the
C API which corresponds to resource creation from within APR, you may expect
a segfault since these sorts of records are constrained to a single flavor
of the MSVCR library.  The httpd/apr distributed by the httpd project is
still built on MSVCRT/VC6.

I understand it's possible to build using the DDK libraries to target the
same MSVCRT, in which case you should have no problems whatsoever.  If you
build for a Studio 2008 SQLite/apr_dbd_sqlite module, then there may be
issues if sqlite allocates memory, etc, under the assumption that the caller
will then free those resources, and similarly the whole dbd interface.