It seems that I mistakenly thought that it had been converted into a struct, 
which is not the case.  Sorry for the false alarm.

Kern

On Sunday 21 June 2009 17:55:43 Dan Langille wrote:
> Kern Sibbald wrote:
> > Hello Dan,
> >
> > This is to warn you that Bacula will probably not be able to be compiled
> > and run with encryption on Release 7 of FreeBSD.  This is because the
> > version of pthreads in that release has pthread_t defined as a structure,
> > which is incompatible with OpenSSL.
>
> Initial conversations indicate that pthread_t is a point to a structure.
>
>  From /usr/include/sys/_pthreadtypes.h
>
>      typedef struct  pthread                 *pthread_t;
>
> See http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/_pthreadtypes.h
>
> Does this help?
>
> > The OpenSSL API mandates doing comparison of
> > thread ids without the use of pthread_equal().  In otherwords, Bacula
> > must be able to return a thread id to OpenSSL when requested.  It
> > currently does so with:
> >
> >    return ((unsigned long)pthread_self());
> >
> > which is far from being elegant, but does currently work on all platforms
> > including FreeBSD < 7 (with the possible exception of Win32).
>
> I am told:
>   - "pthread_t is the type of thread IDs"
>   - "libthr's pthread_equal simply compares the two pointers"
>   - "hmm, I haven't seen any issue with FreeBSD 7.2 and Bacula 3.0.0..."
>   - "if you wanted to do it fully pthread compliant, I think you could
>      use pthread_setspecific() to create your own thread IDs but that's
>      rather ugly.  newer versions of openssl handle this better (where
>      "newer versions" is 0.9.9)"
>
> > This will not work with the new FreeBSD implementation of pthreads.
> > Perhaps the FreeBSD pthreads developers have a FreeBSD specific solution
> > for this problem. If so, could you please let me know.  If not, Bacula
> > encryption will unfortunately not be available on the new version of
> > FreeBSD.
>
> A FreeBSD project
>
> The FreeBSD port applies these thread related patches to the Bacula source:
>
> dan@polo:/usr/ports/sysutils/bacula-server/files] $ cat patch-src_lib_jcr.c
> --- src/lib/jcr.c.orig  2009-04-12 11:07:07.079940037 -0400
> +++ src/lib/jcr.c       2009-04-12 11:07:20.116947254 -0400
> @@ -1063,8 +1063,8 @@
>         fprintf(fp, "\tuse_count=%i\n",
>                 jcr->use_count());
>   #else
> -      fprintf(fp, "\tuse_count=%i threadid=0x%x\n",
> -              jcr->use_count(), (int)jcr->my_thread_id);
> +      fprintf(fp, "\tuse_count=%i threadid=0x%lx\n",
> +              jcr->use_count(), (long)jcr->my_thread_id);
>   #endif
>         fprintf(fp, "\tJobType=%c JobLevel=%c\n",
>                 jcr->get_JobType(), jcr->get_JobLevel());
> [dan@polo:/usr/ports/sysutils/bacula-server/files] $
>
>
>
> --- src/cats/sql.c.orig 2009-04-12 11:07:46.218959381 -0400
> +++ src/cats/sql.c      2009-04-12 11:08:15.509974021 -0400
> @@ -759,7 +759,7 @@
>      if (mdb->lock.valid == RWLOCK_VALID) {
>         fprintf(fp, "\tRWLOCK=%p w_active=%i w_wait=%i\n", &mdb->lock,
> mdb->lock.w_active, mdb->lock.w_wait);
>   #ifndef HAVE_WIN32
> -      fprintf(fp, "\t\tthreadid=0x%x mutex=%p\n",
> (int)mdb->lock.writer_id, &mdb->lock.mutex);
> +      fprintf(fp, "\t\tthreadid=0x%lx mutex=%p\n",
> (long)mdb->lock.writer_id, &mdb->lock.mutex);
>   #endif
>      }
>   }
>
> > Note, as far as I know this means that any program that uses pthreads and
> > OpenSSL will have the same problem.
> >
> > Best regards,
> >
> > Kern



------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users