Summary: | media-video/sswf-1.8.0 amd64: cast void*->int32_t compile error | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Fabio Correa <facorread> |
Component: | New packages | Assignee: | AMD64 Project <amd64> |
Status: | VERIFIED FIXED | ||
Severity: | normal | CC: | media-video |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Evaluate the size of void* while executing sswf::patch()
sswf-1.8.0.ebuild upstream's 64bit patch |
Description
Fabio Correa
2007-03-20 16:22:28 UTC
Created attachment 113883 [details, diff]
Evaluate the size of void* while executing sswf::patch()
This patch is intended to work on 32 and 64-bit platforms, provided int64_t is defined.
Created attachment 113887 [details]
sswf-1.8.0.ebuild
I've tested it with 32bit, and noticed no regressions.. so amd64, if the patch looks allright to you, go ahead.
I sended info on this bug to Alexis Wilke, author of sswf. Here is his reply: Hi Fabio, Yes indeed. The cast to int32_t of pointers is not a good idea. I changed that with intptr_t. This prevents the warning. Now for your fix you need to use 7 and not 4 in your expressions. if(sizeof(void *) == 8 && (size & 7) == 0 && (((intptr_t) s1) & 7) == 0 && (((intptr_t) s2) & 7) == 0) { It is likely to work fine with 4, especially on an INTEL processor which usually does not generate an error when accessing data whatever the address. But 7 is what is correct, you must ensure that all three bits are zero, especially for Macs and IRIX systems. I will put the change up on our FTP very soon. Thank you for the compliments too 8-) Always welcome! Alexis seems like this is fixed upstream, putting ftp://ftp.m2osw.com/sswf/sswf-1.8.0/sswf-1.8.0-src.tar.bz2 (upstream ftp) in distfiles and emerging sswf works for me, the sswf-1.8.0-src.tar.bz2 on the gentoo mirrors doesn't have the patch yet though Adding media-video to CC, please have a look at comment #4 :> (In reply to comment #4) > seems like this is fixed upstream, putting > ftp://ftp.m2osw.com/sswf/sswf-1.8.0/sswf-1.8.0-src.tar.bz2 (upstream ftp) in > distfiles and emerging sswf works for me, the sswf-1.8.0-src.tar.bz2 on the > gentoo mirrors doesn't have the patch yet though ....... changing the tarball while keeping the same name will only break our digests...... Created attachment 116311 [details, diff] upstream's 64bit patch Well ok, I guess a simple redigest wouldn't fix it - so here's the fix used by upstream, nearly the same previously attached to this bug but with the fix mentioned in comment #3 There are actually more changes, but the whole diff of the new source and the tarball on the gentoo mirrors resulted in a 1.8M file ;> (In reply to comment #6) > (In reply to comment #4) > > seems like this is fixed upstream, putting > > ftp://ftp.m2osw.com/sswf/sswf-1.8.0/sswf-1.8.0-src.tar.bz2 (upstream ftp) in > > distfiles and emerging sswf works for me, the sswf-1.8.0-src.tar.bz2 on the > > gentoo mirrors doesn't have the patch yet though > > > ....... changing the tarball while keeping the same name will only break our > digests...... > Yeah, it's lame. Lucky for us they provide both .tar.bz2 and tar.gz so.. 17:33 <+CIA-11> drac * gentoo-x86/media-video/sswf/ (ChangeLog sswf-1.8.0.ebuild files/digest-sswf-1.8.0): 17:33 <+CIA-11> Change tarball from .tar.bz2 to .tar.gz to get a 64bit patch because upstream didn't version bump. 17:33 <+CIA-11> (Portage version: 2.1.2.3) So we should have the patch now. AMD64, reopen if this still doesn't work for you. |