apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 46175] Full Mingw+MSys support
Date Fri, 04 Feb 2011 19:38:59 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=46175

Carlo Bramini <carlo.bramix@libero.it> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #22847|0                           |1
        is obsolete|                            |

--- Comment #5 from Carlo Bramini <carlo.bramix@libero.it> 2011-02-04 14:38:55 EST ---
Created an attachment (id=26607)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26607)
Fix for this bug

After long long time I decided to do another try for improving the support for
mingw+msys on APR.
All my changes were done against the most recent sources I could find into the
SVN repository.
However, I must signal to you that I was not able to create configure script at
first try, I had to process the following sources with dos2unix tool for
changing all CRLF into LF, otherwise the creation failed:

buildconf
build/buildcheck.sh
build/PrintPath
build/get-version.sh

After bypassing this little trouble, I was able to start my inspection.
As you can see, I trashed all previous fixes I did for BeOS since at current
time I could not test them anymore.
I also trashed the fixes to APR_INT64_C and APR_UINT64_C for MSVC.
In the past I did that change because I though that it could be useful to use
directly the apr.h file generated from configure script with mingw in
VisualStudio, perhaps with just some little eventual adjustment if some
libraries are available in mingw at configure time while they are not in MSVC.
In other words, my intention was to create a facility for the maintenance of
apr.hw (you can also notice that I had modified a bit apr.hw to be very similar
to generated apr.h for simplify file comparison), which could be updated with a
simple copy paste action.
Since apr.h.in already included some tests for __GNUC__, I though it would not
be a big problem to add one test for _MSC_VER in that point.

My fixes to current trunk can be resumed as:

1) Build process was not able to create a shared library.
For creating a DLL, libtool requires the -no-undefined flag al linking stage.
This flag has been added in $LT_LDFLAGS macro.
Unfortunately, in some places the $LT_LDFLAGS was placed wrongly before calling
the driver, in other words was at the same level of macro LTFLAGS and as result
those options were given direclt to libtool rather than the driver.
I fixed that mistake in these files:
test/Makefile.in
configure.in

2) I was a bit out of idea when I tried to understand the reasons for testing
shell32, advapi32, ws2_32 and rpcrt4 in that manner in configure script.
Since these tests where done in the mingw section, that reason is still arcane
to me...
Another thing that should be avoided is to add -lkernel32 in the command line:
for some reasons, mingw hates this and anyways you do not need to write them as
well as user32 and msvcrt: you will have them by default.
If you had to add them previously, probably your compiler or at least your SPEC
file is very outdated and so the best solution is to update it.

3) I modified a piece of hand written code for using APR_SETIFNULL instead. I
also added declaration of some variables that may be left empty regarding the
platform.

4) I'm able to compile APR without problems with -O2 flag.
I'm using the stable gcc-3.4.5-20060117-3.
Experimental gcc-4.x probably will work fine too, but I suggest to use the
stable version since it's really stable in its word sense and with my
experience it seems to me it is able to generate more efficient code.
If you are using the cross compiler that you may find in a linux distrubution,
you can encounter problems because some bugs in the toolchain: when working for
building a native port of GUILE for Windows, some people noticed that it was
not able to export data from DLL but only functions, while I was perfectly able
to build it.
It may be possible that the compiler used by somebody in the past had a similar
defect.
If you are working on that bugged cross compiler, the only solution is to
replace it with a working one. You may compile it yourself with the sources of
the mingw stable (that I recommend) or other precompiled binaries, like the
ones provided by mingw-w64 or the ones included into the RosBE enviroment for
linux that we use for compiling ReactOS.
Another alternative that could cause that old trouble at linking could be a
mistake in support macro for forcing the usage of shared runtime (missing _DLL,
__MSVCRT__ and so on...) but since there are not informations about, it's
difficult to make more theories...

5) support/unix/waitio.c failed to compile.
Since the pollset member of apr_file_t structure is made conditional to
APR_FILES_AS_SOCKETS value, I simply added its test.



PROBLEMS:
While I was able to compile and install APR, I got some new problems.

The first problem happened because I installed sqlite3 in my build enviroment.
During configuration, sqlite3 has been detected correctly and enabled.
But when linking the DLL, it showed an error saying that apr_dbd_sqlite3_driver
was undefined.
I do not know what's wrong exactly, but the only solution was to disable
sqlite3 support.

The creation of the DLL also failed because it was not adding iconv when
linking and infact it complained about unresolved libiconv symbols.
Actually I fixed it directly in the generated makefile by manually add
"-liconv" but it must be fixed correctly.
Probably a more cleaner solution exists and perhaps it would be better to trash
all that current code and simply use AM_ICONV for detecting this stuff.


NOTES:
AC_LIBTOOL_WIN32_DLL is (was) a macro for activating the support for the
creation of dynamic linking libraries in Windows.
Although it's deprecated (there is a new technique, as it has also been written
in your configure.in), it will be maintained for compatibility with all future
scripts, at least this is what I remember I read.
But I do not see much relation with your APR_CHECK_DLL_FUNC macro.
Anyways I think it could be removed since it's unused if you will apply my
patch.

Sincerely,

Carlo Bramini.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org


Mime
View raw message