apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 54291] New: Modules build on Windows
Date Thu, 13 Dec 2012 11:21:02 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=54291

            Bug ID: 54291
           Summary: Modules build on Windows
           Product: APR
           Version: HEAD
          Hardware: PC
                OS: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: APR
          Assignee: bugs@apr.apache.org
          Reporter: carlo.bramix@libero.it
    Classification: Unclassified

Created attachment 29751
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=29751&action=edit
Fix for this bug.

With reference to bug #46175, in the past APR failed to build if some packages
were installed in the build environment.
In my case, the build failed because the presence of libsqlite3 and the only
solution was to disable its support with --with-sqlite3=no option at configure
time.
Actually the problem happens because the apr_private.h used here is not the one
generated by the build scripts, but it is always the one stored in
$(srcdir)/include/arch/win32
Compared to the file generated by autotools, this apr_private.h is missing the
declaration of APR_HAVE_MODULAR_DSO and its absence is causing the above
troubles.
Adding APR_HAVE_MODULAR_DSO to apr_private.h for Win32 solves this old trouble
and it is also a safe addition since we are sure that
LoadLibrary()/FreeLibrary() functions are always supported on Windows.

Attached patch fixes the build of APR when it is building in these conditions.

Unfortunately, this patch is not still enough for fixing this defect
completely.
While libapr-2 is built without troubles, after a while the build process is
interrupted because another error:

/bin/sh /d/apr/libtool --silent --mode=link gcc -no-undefined -g -O2  
-Wl,--ena
ble-auto-import,--subsystem,console    -release 2 -module -rpath
/home/Carlo/ins
t_apr/lib/apr-2 -o dbd/apr_dbd_sqlite3.la dbd/apr_dbd_sqlite3.lo -lsqlite3
dbd/.libs/apr_dbd_sqlite3.o: In function `dbd_sqlite3_select_internal':
c:/apr/dbd/apr_dbd_sqlite3.c:107: undefined reference to `apr_palloc@8'
c:/apr/dbd/apr_dbd_sqlite3.c:132: undefined reference to `apr_pstrdup@8'
c:/apr/dbd/apr_dbd_sqlite3.c:128: undefined reference to `apr_palloc@8'
c:/apr/dbd/apr_dbd_sqlite3.c:152: undefined reference to `apr_pstrmemdup@12'

..etc

Evidently, apr_dbd_sqlite3 depends on libapr-2 (and probably other modules will
do the same), so the link step is simply missing "-lapr-2.0" at the end of the
command line.
I manually hacked the generated Makefile to verify that it was just missing
this option and infact, after this thing has been added manually, the entire
APR build has been completely finished (finally!).

Unfortunately, this stuff seems generated by a Python source and I have not the
knowledge to make this fix. Unless I have understood wrongly the place where
this correction must be done, someone else with Python coding experience should
make this last fix.

Sincerely,

Carlo Bramini.

-- 
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