Bug#875456: [Pkg-giraffe-maintainers] Bug#875456: libvmime: FTBFS on non-Linux: no getThreadId implementation

[Carsten Schoenert]

Control: clone -1 -2
Control: retitle -2 libvmime: still FTBFS on Hurd due missed getThreadId 
implementation

Hello Aaron,

On Wed, Sep 13, 2017 at 10:17:44PM -0400, Aaron M. Ucko wrote:
> Guido Günther  writes:
> 
> > Can you send a patch tested on hurd?
> 
> Sure, no problem.  With the attached version of
> adding-alternative-getThreadId-implementation.patch applied, the build
> and the upstream test suite both succeed on the hurd-i386 porter box
> exodar.debian.net.  (NB: The upstream test suite is locale-sensitive; on
> both amd64 and hurd-i386, it succeeds in a UTF-8 locale but eight
> encoding-related tests fail in an ASCII locale.)

thank you for taking care, much appreciated!

It seems you have forgotten to attach the patch. :-)
Could you please add the patch to the cloned new report?

Regards
Carsten

Bug#875456: [Pkg-giraffe-maintainers] Bug#875456: libvmime: FTBFS on non-Linux: no getThreadId implementation

[Aaron M. Ucko]

Guido Günther  writes:

> Can you send a patch tested on hurd?

Sure, no problem.  With the attached version of
adding-alternative-getThreadId-implementation.patch applied, the build
and the upstream test suite both succeed on the hurd-i386 porter box
exodar.debian.net.  (NB: The upstream test suite is locale-sensitive; on
both amd64 and hurd-i386, it succeeds in a UTF-8 locale but eight
encoding-related tests fail in an ASCII locale.)

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#875456: [Pkg-giraffe-maintainers] Bug#875456: libvmime: FTBFS on non-Linux: no getThreadId implementation

[Guido Günther]

Hi,
On Tue, Sep 12, 2017 at 09:12:40PM -0400, Aaron M. Ucko wrote:
> "Aaron M. Ucko"  writes:
> 
> >   /«PKGBUILDDIR»/src/vmime/platforms/posix/posixHandler.cpp:243:3: error: 
> > #error We have no implementation of getThreadId() for this platform!
> 
> Thanks for the quick fix!  Alas, the Hurd build still failed because
> Mach has its own API for this functionality:
> 
>   /<>/src/vmime/platforms/posix/posixHandler.cpp:244:12: error: 
> 'SYS_thr_self' was not declared in this scope
> 
> It looks like it should work to call mach_thread_self() from
> .  However, please bear in mind that you'll
> then need to pass the result to mach_port_deallocate per
> https://bugs.launchpad.net/sbcl/+bug/723581 .

Can you send a patch tested on hurd?
 -- Guido

Bug#875456: libvmime: FTBFS on non-Linux: no getThreadId implementation

[Carsten Schoenert]

Hello Aaron,

On Tue, Sep 12, 2017 at 09:12:40PM -0400, Aaron M. Ucko wrote:
> "Aaron M. Ucko"  writes:
> 
> >   /«PKGBUILDDIR»/src/vmime/platforms/posix/posixHandler.cpp:243:3: error: 
> > #error We have no implementation of getThreadId() for this platform!
> 
> Thanks for the quick fix!

well, I had prepared the now used patch for quite a while but haven't
done a new upload since then, so no real quick working on that to be
fare. But while working on kopanocore it was worth to do a new shot on
libvmime.
There was a bug report [1] about build issues for libvmime on *BSD while
working on that patch, but upstream hasn't implemented anything yet that
could solve this. Later on, (as seen yesterday) a probably better
solution than the patch I've used has been added [2]. But I'm not sure
if this solve the build problem that still exist on Hurd.

>  Alas, the Hurd build still failed because
> Mach has its own API for this functionality:
> 
>   /<>/src/vmime/platforms/posix/posixHandler.cpp:244:12: error: 
> 'SYS_thr_self' was not declared in this scope
> 
> It looks like it should work to call mach_thread_self() from
> .  However, please bear in mind that you'll
> then need to pass the result to mach_port_deallocate per
> https://bugs.launchpad.net/sbcl/+bug/723581 .

I have no great experience about this specific mechanism no matter what
platform on. I appreciate any help from porters here, due the
specialities of Hurd and the current state in Debian I wont spend much
time for working on that.

Maybe I give it a try on a porterbox after adding the upstream fix.

[1] https://github.com/kisli/vmime/issues/177
[2] 
https://github.com/kisli/vmime/commit/243efb267fe539958610ef1e2142a36dfbcd3c28

Regards
Carsten

Bug#875456: libvmime: FTBFS on non-Linux: no getThreadId implementation

[Aaron M. Ucko]

"Aaron M. Ucko"  writes:

>   /«PKGBUILDDIR»/src/vmime/platforms/posix/posixHandler.cpp:243:3: error: 
> #error We have no implementation of getThreadId() for this platform!

Thanks for the quick fix!  Alas, the Hurd build still failed because
Mach has its own API for this functionality:

  /<>/src/vmime/platforms/posix/posixHandler.cpp:244:12: error: 
'SYS_thr_self' was not declared in this scope

It looks like it should work to call mach_thread_self() from
.  However, please bear in mind that you'll
then need to pass the result to mach_port_deallocate per
https://bugs.launchpad.net/sbcl/+bug/723581 .

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#875456: libvmime: FTBFS on non-Linux: no getThreadId implementation

[Aaron M. Ucko]

Source: libvmime
Version: 0.9.2-3
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)

Builds of libvmime 0.9.2 for kFreeBSD and the Hurd (admittedly not
release architectures) have been failing:

  /«PKGBUILDDIR»/src/vmime/platforms/posix/posixHandler.cpp:243:3: error: 
#error We have no implementation of getThreadId() for this platform!

I'm not sure offhand if either has anything quite like Linux's gettid,
but perhaps pthread_self can suffice for libvmime's purposes.  (If so,
you'd want to widen getThreadId's return type to uintptr_t and cast
pthread_self's return value accordingly.)

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu