pam_winbind works perfectly if it is executed by the operating system itself.

The moment you write your own PAM-based application, pam_winbind failes to load 
and you can find syslog entries that indicate that pam_winbind did not load due 
to unresolved symbols.

While searching for possible solutions on the internet, a found a document that 
explicitly stated that a PAM module needs be linked against all resources it 
uses and that there must not be any unresolved symbols.

In fact, the moment I changed my source/Makefile.in from

nsswitch/pam_winbind.@SHLIBEXT@: $(PAM_WINBIND_PICOBJ) bin/.dummy
        @echo "Linking $@"
        @$(SHLD) $(LDSHFLAGS) -o $@ $(PAM_WINBIND_PICOBJ) \
                @SONAMEFLAG@`basename $@` -lpam

to

nsswitch/pam_winbind.@SHLIBEXT@: $(PAM_WINBIND_PICOBJ) bin/.dummy
        @echo "Linking $@"
        @$(SHLD) $(LDSHFLAGS) -o $@ $(PAM_WINBIND_PICOBJ) \
                -Wl,--no-undefined \
                -lpam $(DYNEXP) -lsocket -lc \
                @SONAMEFLAG@`basename $@`

on my Solaris 8 box, my own application program worked immediately.

Since the libraries required to satisfy the --no-undefined rule are rather 
platform dependent, a fix probably requires some additional configuration 
macros.

On the other hand, for somemone who is not really experienced in that 
programming field, this problem is really tough to tackle ...