Skip to content
  1. Oct 03, 1998
  3. Oct 02, 1998
    • Ken Coar's avatar
      · 3dfb6b39
      Ken Coar authored 
      	Back off a portion of the incremental-IndexOptions patch;
	unprefixed keywords should clear all inherited options and
	start setting the local directory's options from scratch.
	Otherwise, 'keyword' and '+keyword' are essentially identical,
	and clearing inheritance a pain.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82194 13f79535-47bb-0310-9956-ffa450edef68
      3dfb6b39
  5. Oct 01, 1998
  7. Sep 30, 1998
  9. Sep 28, 1998
    • Ken Coar's avatar
      · d1b69730
      Ken Coar authored 
      	There appear to be no dissenters (other than for brand-new and
	incompatible syntaxes) after three days, and I want to get this
	in for 1.3.3.  It can always be modified or reverted later.

	Add +/- prefixes to IndexOptions keywords, allow merging of
	multiple occurrences, and document the changes.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82175 13f79535-47bb-0310-9956-ffa450edef68
      d1b69730
  11. Sep 27, 1998
  13. Sep 24, 1998
  15. Sep 17, 1998
  17. Sep 13, 1998
  19. Sep 12, 1998
  21. Sep 10, 1998
  23. Sep 09, 1998
  25. Sep 08, 1998
  27. Sep 07, 1998
  29. Sep 06, 1998
  31. Sep 04, 1998
  33. Sep 02, 1998
    • Ken Coar's avatar
      · dbcd76fe
      Ken Coar authored 
      	Update the filname column width-sizing piece of mod_autoindex
	so that it's customisable with a NameLength keyword on the
	IndexOptions directive.  A value of '*' means 'as wide as the
	longest filename,' which was the default effect of the last
	patch in this area.

PR:	1949, 2324


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@81979 13f79535-47bb-0310-9956-ffa450edef68
      dbcd76fe
  35. Aug 31, 1998
    • Ken Coar's avatar
      · 8794b635
      Ken Coar authored 
      	Clean up mod_autoindex's storage of the IndexOptions settings.
	They are per-directory, not per-filename, so keeping them in
	an array is confusing and pointless.  They're now stored in an
	int in the module config record.  Also (finally!) fix the
	FancyIndexing directive so it gets merged into any IndexOptions
	settings for the current directory, rather than replacing them.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@81972 13f79535-47bb-0310-9956-ffa450edef68
      8794b635
  37. Aug 27, 1998
  39. Aug 24, 1998
  41. Aug 19, 1998
  43. Aug 16, 1998
  45. Aug 12, 1998
  47. Aug 11, 1998
  49. Aug 10, 1998
  51. Aug 06, 1998
  53. Aug 05, 1998
  55. Aug 03, 1998
    • Ralf S. Engelschall's avatar
      Link DSO modules against possible libraries from $(LIBS) (take 2) · e743d2fa
      Ralf S. Engelschall authored 
      =================================================================

Currently we have the following entry in our dso.html document:

| Because DSO modules cannot be linked against other DSO-based libraries (ld
| -lfoo) on all platforms (for instance a.out-based platforms usually don't
| provide this functionality while ELF-based platforms do) you cannot use the
| DSO mechanism for all types of modules. Or in other words, modules compiled as
| DSO files are restricted to only use symbols from the Apache core, from the C
| library (libc) and all other dynamic or static libraries used by the Apache
| core, or from static library archives (libfoo.a) containing position
| independend code. The only chance to use other code is to either make sure the
| Apache core itself already contains a reference to it or loading the code
| yourself via dlopen().

The important part here is: "cannot be linked .... on all platforms".  But
there _are_ platform (especially ELF-based ones) which support linking DSO
files agains other DSO files.  And even on platforms where this is not
possible is it possible to at least link against libraries assuming they
contain PIC code.

So, the idea is this: In the configuration process we already determine the
variable LDFLAGS and LIBS. They hold -L and -l options for linking
executables.  We parse these options and separate them into three classes:
OBJ, PIC and DSO.  And then we re-assemble a LIBS_SHLIB variable from only the
options in classes PIC and DSO. This variable is then used on the build
command for mod_xxx.so.

Example:

| $ ./configure --prefix=/tmp/apache \
|               --enable-module=auth_db \
|               --enable-shared=auth_db \
|               --enable-rule=SHARED_CHAIN

Without SHARED_CORE the mod_auth_db.so cannot be linked or at least not loaded
correctly under run-time. With SHARED_CHAIN enabled it is linked against the
libdb.so and all is fine (at least under this ELF-based Debian box I tried):

| :> make mod_auth_db.so
| gcc -c  -I../../os/unix -I../../include -I/usr/include/  -DLINUX=2
| -DUSE_HSREGEX `../../apaci` -fpic -DSHARED_MODULE mod_auth_db.c && mv
| mod_auth_db.o mod_auth_db.lo
| ld -Bshareable -o mod_auth_db.so mod_auth_db.lo -lm -ldb
| root@gw1:/e/apache/SRC/WORK/apache-1.3-libsshlib/src/modules/standard
| :> ldd mod_auth_db.so
|         ./mod_auth_db.so => ./mod_auth_db.so
|         libc.so.5 => /lib/libc.so.5
|         libm.so.5 => /lib/libm.so.5
|         libdb.so.1 => /usr/lib/libdb.so.1

This way we provide the maximum we can provide. Sure, on some platforms the
user still has no chance. But this shouldn't mean he becomes no chance on
other platforms where there _is_ a chance. So this patch is a first step for
more friendly and flexible DSO support.

The complete mechanism is triggered by a new Rule named SHARED_CHAIN. To avoid
problems this is DISABLED(!) for ALL(!) platforms currently. But when
experience shows that it worked fine for users we can enable it for tested
platforms per default.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@81846 13f79535-47bb-0310-9956-ffa450edef68
      e743d2fa