Version 2.7 and 3.0 of mod_wsgi now available.

[Graham Dumpleton]

Have fun.

http://code.google.com/p/modwsgi/wiki/ChangesInVersion0207
http://code.google.com/p/modwsgi/wiki/ChangesInVersion0300

Version 3.0 is same as last release candidate exception for version
string embedded within it.

Version 2.7 is just to get out what changes had been sitting in 2.X branch.

Graham

[Douglas Thrift]

Wow!

So I decided to start working on upgrading the FreeBSD port to 2.7
before figuring out what to do about 3.0. And I got the following:

[douglas@slowhand:mod_wsgi]$ make
===> Extracting for mod_wsgi-2.7
=> MD5 Checksum OK for mod_wsgi-2.7.tar.gz.
=> SHA256 Checksum OK for mod_wsgi-2.7.tar.gz.
===> Patching for mod_wsgi-2.7
===> mod_wsgi-2.7 depends on file: /usr/local/bin/python2.6 - found
===> mod_wsgi-2.7 depends on file: /usr/local/sbin/apxs - found
===> Configuring for mod_wsgi-2.7
checking Apache version... 2.2.13
configure: creating ./config.status
config.status: creating Makefile
===> Building for mod_wsgi-2.7
/usr/local/sbin/apxs -c -I/usr/local/include/python2.6 -DNDEBUG
-D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x20000 -O2 -fno-strict-aliasing
-pipe -march=nocona mod_wsgi.c -L/usr/local/lib
-L/usr/local/lib/python2.6/config -lpython2.6 -lutil -lm
apxs:Error: Unknown option: O.
apxs:Error: Unknown option: 2.
apxs:Error: Unknown option: f.
apxs:Error: Unknown option: m.
apxs:Error: Unknown option: r.
apxs:Error: Unknown option: h.
apxs:Error: Unknown option: =.
Usage: apxs -g [-S <var>=<val>] -n <modname>
apxs -q [-S <var>=<val>] <query> ...
apxs -c [-S <var>=<val>] [-o <dsofile>] [-D <name>[=<value>]]
[-I <incdir>] [-L <libdir>] [-l <libname>] [-Wc,<flags>]
[-Wl,<flags>] [-p] <files> ...
apxs -i [-S <var>=<val>] [-a] [-A] [-n <modname>] <dsofile> ...
apxs -e [-S <var>=<val>] [-a] [-A] [-n <modname>] <dsofile> ...
*** Error code 1
1 error
*** Error code 1

Stop in /home/douglas/ports/www/mod_wsgi.

Not sure what's going on here. :(

Thanks!
--
Douglas William Thrift
<dougl...@gmail.com>
<http://douglasthrift.net/>

> --
>
> You received this message because you are subscribed to the Google Groups "modwsgi" group.
> To post to this group, send email to mod...@googlegroups.com.
> To unsubscribe from this group, send email to modwsgi+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/modwsgi?hl=.
>
>

[Clodoaldo Neto]

2009/11/21 Douglas Thrift <dougl...@gmail.com>:

It looks like issue 166:

http://code.google.com/p/modwsgi/issues/detail?id=166

Regards, Clodoaldo

[Graham Dumpleton]

Is it some policy with FreeBSD builds that it always supplies some
arbitrary set of CFLAGS in the environment of the 'configure' script
to try and enforce some particular compiler options?

This would only fail if CFLAGS is being set. Previously they would
have been ignored.

Clodoaldo rightly points out the issue:

http://code.google.com/p/modwsgi/issues/detail?id=166

with the original issue where someone asked for the change being:

http://code.google.com/p/modwsgi/issues/detail?id=164&can=1&start=100

When using CFLAGS was added, that original person didn't report an
issue around needing to use -Wc, as prefix to arguments.

As mentioned in subsequent report about it, as I say, automatically
adding -Wc, with mod_wsgi configure script can be a bit of a problem
in itself.

I need to do some research on how other Apache modules with configure
scripts handle this unless someone else already knows of a full proof
scheme. Any scheme needs to deal with options already having -Wc,
prefix. Values to options with quoted strings having spaces etc.
Although, for the latter no one should be setting such problematic
options for mod_wsgi I guess.

All I know is I got tripped up really badly at one point when trying
to do similar -Wl, fiddles in LDFLAGS.

Graham

2009/11/22 Douglas Thrift <dougl...@gmail.com>:

[Graham Dumpleton]

Oh, should mention that quick workaround is obviously to do:

CFLAGS='' ./configure

Graham

2009/11/22 Graham Dumpleton <graham.d...@gmail.com>:

[Douglas Thrift]

Yeah, the Ports system passes global CFLAGS in so system specific
optimizations and other such things can occur.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-cflags.html

After reading Clodoaldo's response earlier I implemented a solution to
add "-Wc," to options that don't have a "-W?" prefix. However, upon
further inspection it looks like you can just pass all of CFLAGS in one
option (-Wc,"$(CFLAGS)"). Perhaps that is the way to go?

[Clodoaldo Neto]

2009/11/22 Graham Dumpleton <graham.d...@gmail.com>:

> Is it some policy with FreeBSD builds that it always supplies some
> arbitrary set of CFLAGS in the environment of the 'configure' script
> to try and enforce some particular compiler options?

It also fails when building 2.7 rpms with mock in Fedora. Mock build.log:

ENTER do(['bash', '--login', '-c', 'rpmbuild -bb --target i386
--nodeps builddir/build/SPECS/mod_wsgi.spec'], False,
'/var/lib/mock/epel-5-i386/root/', None, 0, True, 0, 503, 484, None,
logger=<mock.trace_d
ecorator.getLog object at 0x1f9a510>)
Executing command: ['bash', '--login', '-c', 'rpmbuild -bb --target
i386 --nodeps builddir/build/SPECS/mod_wsgi.spec']
Building target platforms: i386
Building for target i386
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.64350
+ umask 022
+ cd /builddir/build/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ cd /builddir/build/BUILD
+ rm -rf mod_wsgi-2.7
+ /bin/gzip -dc /builddir/build/SOURCES/mod_wsgi-2.7.tar.gz
+ tar -xf -
tar: Read 4608 bytes from -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd mod_wsgi-2.7
++ /usr/bin/id -u
+ '[' 503 = 0 ']'
++ /usr/bin/id -u
+ '[' 503 = 0 ']'
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.64350
+ umask 022
+ cd /builddir/build/BUILD
+ cd mod_wsgi-2.7
+ LANG=C
+ export LANG
+ unset DISPLAY
+ CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386
-mtune=generic -fasynchronous-unwind-tables'
+ export CFLAGS
+ CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386
-mtune=generic -fasynchronous-unwind-tables'
+ export CXXFLAGS
+ FFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386
-mtune=generic -fasynchronous-unwind-tables'
+ export FFLAGS
++ find . -name config.guess -o -name config.sub
+ ./configure --build=i686-redhat-linux-gnu
--host=i686-redhat-linux-gnu --target=i386-redhat-linux-gnu
--program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin
--sbindir=/usr/sbin --sysconfdir=
/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib
--libexecdir=/usr/libexec --localstatedir=/var
--sharedstatedir=/usr/com --mandir=/usr/share/man
--infodir=/usr/share/info
checking for apxs2... no
checking for apxs... /usr/sbin/apxs
checking Apache version... 2.2.3
checking for python... /usr/bin/python

configure: creating ./config.status
config.status: creating Makefile

/usr/sbin/apxs -c -I/usr/include/python2.4 -DNDEBUG -D_GNU_SOURCE -O2
-g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasync
hronous-unwind-tables mod_wsgi.c -L/usr/lib -lpython2.4 -lpthread
-ldl -lutil -lm
+ make LDFLAGS=-L/usr/lib -j4

apxs:Error: Unknown option: O.

Clodoaldo

[Damjan]

> Have fun.
>
> http://code.google.com/p/modwsgi/wiki/ChangesInVersion0207http://code.google.com/p/modwsgi/wiki/ChangesInVersion0300

>
> Version 3.0 is same as last release candidate exception for version
> string embedded within it.

anyone knows of Ubuntu Karmic packages for mod_wsgi 3.0?
or at least a recipe for building a proper package?

[Graham Dumpleton]

2009/11/23 Damjan <gda...@gmail.com>:

Build from source code yourself as per instructions on mod_wsgi site
or in the source README.

The issue being discussed here only relates to the build scripts that
Unix distributions wrap around the mod_wsgi configure/make to package
it up for the binary repositories.

Building it yourself from source code is not affected and should work.

I'll put out a patch for the CFLAGS stuff later today if get time.

Graham

[Graham Dumpleton]

2009/11/23 Graham Dumpleton <graham.d...@gmail.com>:

For now use the following patches.

The issue of embedded spaces probably doesn't cause a problem because
both halves will be prefixed and apxs will then remove prefix from
both and pass in as originally supplied.

Also no need to worry about arguments already using -Wc, as apxs will
again strip off duplicate and original -Wc, will still get through
compiler as originally intended.

I can see now how my -Wl, problems were different as in that case apxs
wasn't just using it as magic prefix that got stripped off again
anyway.

Index: configure
===================================================================
--- configure (revision 1487)
+++ configure (working copy)
@@ -1851,16 +1851,22 @@
fi

CFLAGS1=""
+for arg in ${CFLAGS}
+do
+ CFLAGS1="${CFLAGS1} -Wc,$arg"
+done
+
+CFLAGS2=""
if test -x /usr/bin/lipo; then
LDFLAGS3=""
ARCHITECTURES=`/usr/bin/lipo -info $HTTPD | sed -e 's/.*://'`
for ARCH in $ARCHITECTURES; do
- CFLAGS1="${CFLAGS1} -Wc,'-arch ${ARCH}'"
+ CFLAGS2="${CFLAGS2} -Wc,'-arch ${ARCH}'"
LDFLAGS3="${LDFLAGS3} -arch ${ARCH}"
done
fi

-CFLAGS="${CFLAGS} ${CFLAGS1}"
+CFLAGS="${CFLAGS1} ${CFLAGS2}"
LDFLAGS="${LDFLAGS} ${LDFLAGS1} ${LDFLAGS2} ${LDFLAGS3}"
LDLIBS="${LDLIBS} ${LDLIBS1} ${LDLIBS2} ${LDLIBS3}"

Index: configure.ac
===================================================================
--- configure.ac (revision 1487)
+++ configure.ac (working copy)
@@ -141,16 +141,22 @@
fi

CFLAGS1=""
+for arg in ${CFLAGS}
+do
+ CFLAGS1="${CFLAGS1} -Wc,$arg"
+done
+
+CFLAGS2=""
if test -x /usr/bin/lipo; then
LDFLAGS3=""
ARCHITECTURES=`/usr/bin/lipo -info $HTTPD | sed -e 's/.*://'`
for ARCH in $ARCHITECTURES; do
- CFLAGS1="${CFLAGS1} -Wc,'-arch ${ARCH}'"
+ CFLAGS2="${CFLAGS2} -Wc,'-arch ${ARCH}'"
LDFLAGS3="${LDFLAGS3} -arch ${ARCH}"
done
fi

-CFLAGS="${CFLAGS} ${CFLAGS1}"
+CFLAGS="${CFLAGS1} ${CFLAGS2}"
LDFLAGS="${LDFLAGS} ${LDFLAGS1} ${LDFLAGS2} ${LDFLAGS3}"
LDLIBS="${LDLIBS} ${LDLIBS1} ${LDLIBS2} ${LDLIBS3}"



Committed in subversion trunk at revision 1488. The trunk commit also
updates version string in mod_wsgi.c as well to 3.1-TRUNK.

Graham

[Graham Dumpleton]

If people just want to validate that 2.8 and 3.1 in subversion work
for builds done by package installers, I'll quickly roll some new
versions to address the CFLAGS issue. Details at:

http://code.google.com/p/modwsgi/wiki/ChangesInVersion0208
http://code.google.com/p/modwsgi/wiki/ChangesInVersion0301

Graham

[Douglas Thrift]

Ack!

I just got 2.7 into FreeBSD ports with your patch and 3.0 was compiling
with the patch.

--
Douglas William Thrift
<dougl...@gmail.com>
<http://douglasthrift.net/>

Graham Dumpleton wrote:

[Douglas Thrift]

That is to say that I'm OK with just using a patch and leaving it at 2.7
and 3.0.

--
Douglas William Thrift
<dougl...@gmail.com>
<http://douglasthrift.net/>

[Clodoaldo Neto]

2009/11/23 Graham Dumpleton <graham.d...@gmail.com>:

> If people just want to validate that 2.8 and 3.1 in subversion work
> for builds done by package installers, I'll quickly roll some new
> versions to address the CFLAGS issue. Details at:

Both 2.8 (1489) and 3.1 (1488) build cleanly with Mock in Fedora.

Clodoaldo

[gert]

On Nov 23, 11:55 am, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:

> If people just want to validate that 2.8 and 3.1 in subversion work
> for builds done by package installers, I'll quickly roll some new
> versions to address the CFLAGS issue. Details at:
>
> http://code.google.com/p/modwsgi/wiki/ChangesInVersion0208http://code.google.com/p/modwsgi/wiki/ChangesInVersion0301
>

Works for me.

checking Apache version... 2.2.14

configure: creating ./config.status
config.status: creating Makefile

/usr/httpd/bin/apxs -c -I/usr/include/python3.1 -DNDEBUG mod_wsgi.c -
L/usr/lib -L/usr/lib/python3.1/config -lpython3.1 -lpthread -ldl -
lutil -lm
/usr/httpd/build/libtool --silent --mode=compile gcc -prefer-pic -O2 -
DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -pthread -I/usr/httpd/include -I/
usr/httpd/include -I/usr/httpd/include -I/usr/include/python3.1 -
DNDEBUG -c -o mod_wsgi.lo mod_wsgi.c && touch mod_wsgi.slo
In file included from /usr/include/python3.1/Python.h:8,
from mod_wsgi.c:135:
/usr/include/python3.1/pyconfig.h:1075:1: warning: "_POSIX_C_SOURCE"
redefined
In file included from /usr/include/sys/types.h:27,
from /usr/httpd/include/apr.h:127,
from /usr/httpd/include/ap_config.h:25,
from /usr/httpd/include/httpd.h:43,
from mod_wsgi.c:34:
/usr/include/features.h:158:1: warning: this is the location of the
previous definition
In file included from /usr/include/python3.1/Python.h:8,
from mod_wsgi.c:135:
/usr/include/python3.1/pyconfig.h:1094:1: warning: "_XOPEN_SOURCE"
redefined
In file included from /usr/include/sys/types.h:27,
from /usr/httpd/include/apr.h:127,
from /usr/httpd/include/ap_config.h:25,
from /usr/httpd/include/httpd.h:43,
from mod_wsgi.c:34:
/usr/include/features.h:160:1: warning: this is the location of the
previous definition
/usr/httpd/build/libtool --silent --mode=link gcc -o mod_wsgi.la -
rpath /usr/httpd/modules -module -avoid-version mod_wsgi.lo -L/usr/
lib -L/usr/lib/python3.1/config -lpython3.1 -lpthread -ldl -lutil -lm
/usr/httpd/bin/apxs -i -S LIBEXECDIR=/usr/httpd/modules -n 'mod_wsgi'
mod_wsgi.la
/usr/httpd/build/instdso.sh SH_LIBTOOL='/usr/httpd/build/libtool'
mod_wsgi.la /usr/httpd/modules
/usr/httpd/build/libtool --mode=install cp mod_wsgi.la /usr/httpd/
modules/
cp .libs/mod_wsgi.so /usr/httpd/modules/mod_wsgi.so
cp .libs/mod_wsgi.lai /usr/httpd/modules/mod_wsgi.la
cp .libs/mod_wsgi.a /usr/httpd/modules/mod_wsgi.a
chmod 644 /usr/httpd/modules/mod_wsgi.a
ranlib /usr/httpd/modules/mod_wsgi.a
PATH="$PATH:/sbin" ldconfig -n /usr/httpd/modules
----------------------------------------------------------------------
Libraries have been installed in:
/usr/httpd/modules

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,--rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
chmod 755 /usr/httpd/modules/mod_wsgi.so

[Graham Dumpleton]

Why did the email subject say:

Subject: ports/140805: Update port: www/mod_wsgi Upgrade to 2.6

when it was for 2.7?

http://groups.google.com/group/lucky.freebsd.ports.bugs.digest/browse_frm/thread/1d5e5b72eb25f258/8efe0ec2aa02104f?q=mod_wsgi

Was it meant to imply upgrade to existing 2.6 to replace it with 2.7.

Just thought it was strangely described.

Graham

2009/11/23 Douglas Thrift <dougl...@gmail.com>:

[Douglas Thrift]

Oh, yeah, I hastily typed the subject. If you look at the contents it's
actually 2.7.

> For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
>
>

[Damjan]

> >>http://code.google.com/p/modwsgi/wiki/ChangesInVersion0207http://code...

>
> >> Version 3.0 is same as last release candidate exception for version
> >> string embedded within it.
>
> > anyone knows of Ubuntu Karmic packages for mod_wsgi 3.0?
> > or at least a recipe for building a proper package?
>
> Build from source code yourself as per instructions on mod_wsgi site
> or in the source README.

yeah I did that before asking, and just for the record: there was NO
problem on either ArchLinux 32bit&64bit or Ubuntu Karmic 32bit

I just wanted to play nice with the distribution, that's why I was
asking for a package.

--
damjan

[Graham Dumpleton]

Verisons 2.8 and 3.1 are now out to address the CFLAGS issue. No other
real changes so if you are happily using 2.7 or 3.0, there is not need
to update. These updates are more to allow package distributors
cleanly build it without a local patch.

Graham

2009/11/24 Damjan <gda...@gmail.com>: