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: > > d...@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()); > [...@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
