Re: linuxconf problem solved (sort of)

[Andreas Jaeger <aj@arthur.rhein-neckar.de>]

>>>>> Jack Howarth writes:

Jack> Ulrich,
Jack>    I am not sure how I can write a test case on my machine if dlopen
Jack> is broken on it (since I have never coded for dls before and would
Jack> be totally uncertain if I had written good code). If you have a machine
Jack> which you believe has a flawless dlopen I can suggest a good testcase
Jack> (which probably should be added to the glibc test suite if one like it
Jack> isn't present). I would have a test consisting of a main program and
Jack> a dynamic shared lib. The main program would pass an angle to the shared
Jack> lib. The shared lib would do a cosine on the angle and pass the results
Jack> back. Only the shared lib would be linked against libm.so. The main program
Jack> would not.
Jack>    If I understand the problem we are seeing correctly this test case
Jack> should fail for us unless we force the main program to be linked against

Just a short note about debugging (!) such problems.  glibc 2.1 test
releases have implemented LD_DEBUG.  Just set the variable in your
environment like:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ LD_DEBUG=help /bin/ls
Valid options for the LD_DEBUG environment variable are:

  bindings  display information about symbol binding
  files     display processing of files and libraries
  help      display this help message and exit
  libs      display library search paths
  reloc     display relocation processing
  symbols   display symbol table processing
  versions  display version dependencies

To direct the debugging output into a file instead of standard output
a filename can be specified using the LD_DEBUG_OUTPUT environment variable.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Following your suggestion I wrote two small test programs:
tang.c:
#define  __NO_MATH_INLINES 1
#include <math.h>

double angle (int x)
{
  return cos((double)x);
}

main.c:
#include <stdlib.h>
#include <dlfcn.h>

/*extern double angle (int x);*/

typedef double (*func) (int);

int main(void)
{
  void *y;
  void *x = dlopen("libtang.so", RTLD_LAZY);
  if(x == NULL) {
    printf("dlopen: %s\n", dlerror());
    return -1;
  } else {
    func angle = dlsym (x, "angle");
    if(angle == NULL) {
      printf("dlopen: %s\n", dlerror());
      return -1;
    }
    printf ("%f\n", angle (2.9));
    
  }
  
  dlclose(x);
}

and compiled them with:
gcc -fPIC -shared tang.c -o libtang.so -lm
gcc main.c   -o main -ldl

And everything seems to work (note the debug output!):
$ LD_LIBRARY_PATH=. ./main
-0.416147

$ LD_DEBUG=files LD_LIBRARY_PATH=. ./main
[...]
30763:  transferring control: ./main
30763:
30763:  file=libtang.so;  generating link map
30763:    dynamic: 0x4001696c  base: 0x40014000   size: 0x00002a28
30763:      entry: 0x40014870  phdr: 0x40014034  phnum:          3
30763:
30763:
30763:  file=libm.so.6;  needed by ./libtang.so
30763:  file=libm.so.6;  generating link map
30763:    dynamic: 0x4011fd64  base: 0x40104000   size: 0x0001be30
30763:      entry: 0x40107d90  phdr: 0x40104034  phnum:          5
[...]

My system: i486, glibc 2.0.99, Linux 2.1.125, egcs 1.1.

Do you get the same results?

Btw. if this works for you, then dig out the pam sources and check
what's different to my program.  Manipulate my programs so long until
it resembles the failing pam module.  If it fails for you, then tell
us who to reproduce it.  If you come up with a small test program
which fails on your system (but shouldn't fail according to the
documentation), somebody might look into it.

Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de