On 01/13/2010 01:32 PM, DRC wrote:
> Antoine Martin wrote:
>
>> trunk and 1.0.0 can now build fine, I had to patch this file though (for
>> both):
>>
>> It wouldn't be too hard to hook up a patch phase into the build scripts,
>> but it may not be worth it as the new libdrm releases should have
Antoine Martin wrote:
> trunk and 1.0.0 can now build fine, I had to patch this file though (for
> both):
>
> It wouldn't be too hard to hook up a patch phase into the build scripts,
> but it may not be worth it as the new libdrm releases should have some
> form of darwin/osx support included i
[snip]
I have not seen the
problem with fls() that you describe above. Under what
circumstances do
you see that?
>>> Just a normal build (as above): cd tigervnc-1.0.0/unix&& ./configure&&
>>> make
>>>
>>> Not sure how to build from svn as there is no "./configure" script i
On 01/12/2010 12:56 PM, DRC wrote:
> Antoine Martin wrote:
>
>>> How is this related? The bug my E-Mail was referring to was in the OS X
>>> linker, and the patch that worked around it in the TigerVNC build has
>>> been checked in to trunk for quite some time.
>>>
>> Was this before or
Antoine Martin wrote:
>> How is this related? The bug my E-Mail was referring to was in the OS X
>> linker, and the patch that worked around it in the TigerVNC build has
>> been checked in to trunk for quite some time.
> Was this before or after 1.0 was released?
> I was building from the tigervnc
On 10/08/2009 04:59 PM, DRC wrote:
> The problem has been isolated and worked around. The issue is that the
> OS X linker doesn't seem to honor the request to align code segments to
> 16-byte boundaries. This has been a problem all along, but for some
> reason, when using the OS X 10.4 linker, th
The problem has been isolated and worked around. The issue is that the
OS X linker doesn't seem to honor the request to align code segments to
16-byte boundaries. This has been a problem all along, but for some
reason, when using the OS X 10.4 linker, the problem somehow escaped
detection. The w
Adam Tkac wrote:
> Hm, this is a nasty problem and finding the solution will be even nastier.
>
> I have no experience with Xcode but I would recommend to build library
> without all optimizations (disable both compiler and nasm
> optimizations) and check if it is still broken.
>
Yep. Still bro
On Thu, Oct 01, 2009 at 11:49:50PM -0500, DRC wrote:
> I've uncovered a pretty serious problem with libjpeg/SIMD whenever it is
> built with Xcode 3.x on OS X 10.5 or 10.6. It basically generates a
> corrupted JPEG stream. This problem occurs only with the SIMD
> extensions enabled, but it also o
I've uncovered a pretty serious problem with libjpeg/SIMD whenever it is
built with Xcode 3.x on OS X 10.5 or 10.6. It basically generates a
corrupted JPEG stream. This problem occurs only with the SIMD
extensions enabled, but it also occurs on older revisions of the library
(prior to any modific
10 matches
Mail list logo
