Chris Bagwell on 03/01/2012 11:20 AM wrote:
> Can you test a possible fix since you have access? They appear to be
> using an unsigned pointer so traditional "-1" can't be used. In
> sanei_thread.c, modify these three blocks:
Close. The attached patch fixes the compile issue and the resulting DL
Hi All/Chris,
Fedora (17) is moving away from mingw.org to the w64 MinGW environment.
The w64 folks have a new pthreads implementation called "winpthreads"
and I have encountered an issue with it when compiling sane-backends.
For the Windows build you try to expand the pthread_t pointer. Under
Chris Bagwell on 12/18/2011 09:56 PM wrote:
> Not really. I'm sure upstream libusb is the best place to discuss.
>
> As long as libusb project has a suggested work around/file location
> for dealing with w64, we can accommodate it as well as standard usb.h
> easy enough.
After thinking about it,
On 12/18/2011 09:56 PM, Chris Bagwell wrote:
> I looked at this change but as it is, it breaks compiles on Fedora 16.
> It looks like including the DDK files is the only option there. Is
> there a standard way to check when your on a w64 platform? I guess we
> could move some header file checks
MinGW thread time again.
The MinGW world has been split into two trees. The original mingw.org
tree and the new w64 tree. Fedora, and other distros, are migrating from
mingw.org to w64. Sane-backends will compile and run under the w64
environment with a few caveats.
1. The DDK includes are not
On 11/07/2011 09:56 PM, Chris Bagwell wrote:
> I got it working. It was minor changes to enable winsock2 correctly
> and how to set up non-blocking.
Ah, glad to hear it.
>Now thats the way to develop windows applications.
Yes it is. If you ever need any assistance feel free to pop questions
Michael Cronenworth wrote:
> The resulting 1.0.23 DLL doesn't even find the USB device so maybe
> something is up with libusb. I'll keep looking.
It helps if I have libusb in my 64-bit MinGW environment.
Rebuilding SANE 1.0.23 results in a working, scanning 64-bit DLL! Woo hoo.
Michael Cronenworth wrote:
> Unfortunately this trick doesn't make the 64-bit DLL work. Something
> else is wrong.
My previous message was when I compiled for 32-bit only. The 64-bit DLL
I was using was the 1.0.21 version.
The 64-bit compile against the latest git code doesn'
Michael Cronenworth wrote:
> I'll try the latest git checkout plus this patch and see if it works any
> better for me.
The latest git + only your patch now compiles on the first try. However,
the resulting DLL doesn't find the scanner. sane-find-scanner.exe finds
the
Chris Bagwell wrote:
> I'm looking for a reviewer of attached patch and I'm also hoping
> someone has a scanner who's driver uses threads can test this patch to
> verify no regressions occurred (be sure and use --enable-pthread on
> configure).
>
> Current code assumes/requires that SANE_Pid is rep
On 11/04/2011 07:49 PM, Chris Bagwell wrote:
> I can't comment much on this part. Lots of changes occurred.
OK. I'll keep investigating, but I don't have a lot of time to invest in
it so since 1.0.21 works I may stick with that.
>
> I've had your patches sitting in my inbox since 2009. Never go
Hello,
In the past I posted about building for Windows. I had SANE 1.0.21
working fine. Today I have tried to build 1.0.22 and test it. The build
works fine, but when I use the resulting DLL the scanner cannot be seen.
Switching back to the 1.0.21 DLL makes the scanner visible again.
Is there
On 11/11/2009 11:22 PM, stef wrote:
> Running your scanner from a vmware windows guest OS will work.
>
Use VirtualBox instead.
Chris Bagwell on 06/26/2009 11:25 AM wrote:
>
> I was going to attempt to submit at least non-issue chunks of your
> patches (for example, anything under "lib/" which is to support
> multiple platforms anyways). Last email I saw from you, you mentioned
> going to re-update your patches so I held
David Solomon on 06/26/2009 10:45 AM wrote:
> Is there any way to disable the usage globally for testing?
>
If you search through the mailing list archives you should find my MinGW
patches (still don't seem to be accepted by the maintainers?) and
compile a native libsane.dll unless you require s
Original Message
Subject: Re: [sane-devel] Git repositories are up
From: Alessandro Zummo
To: Julien BLACHE
Date: 05/26/2009 04:12 PM
>
>
> you mean parse the output of git log ?
> i seems quite detailed, I'd just use that on
>
You can use kernel.org as a model. Example:
m. allan noah wrote:
> so you've made it unsigned long? what happens in places where the
> value is set to or checked for -1 (avision.c) ?
>
I had to change those returns and surrounding functions. More work may
need to be done.
m. allan noah wrote:
> yes- it would be nice if SANE_Pid was an opaque type, perhaps just an
> array index or pointer to a struct. Right now the ranges of valid
> values are not the same pthread vs fork.
>
Actually I changed the typedef in sanei_thread.h from long to type
pthread_t and made ot
Hi,
In sanei/sanei_thread.c there's this little tid-bit of code:
DBG( 2, "pthread_create() created thread %ld\n", (SANE_Pid)thread );
"thread" is of type pthread_t, which is an extremely opaque type. You
won't get a reliable answer by casting it as long and printing it for
debugging purposes.
Original Message
Subject: [sane-devel] MinGW, Win32, git, and io.h
From: Michael Cronenworth
To: SANE Mailing List
Date: 05/04/2009 04:45 PM
> Not good.
>
> The requirement in sanei for io.h means that a Win32 build isn't
> possible. I'm assuming you ar
Not good.
The requirement in sanei for io.h means that a Win32 build isn't
possible. I'm assuming you are using inb() and outb() to require io.h. I
don't know of any Win32 replacements off the top of my head.
This may not be a show stopper, as the fujitsu backend does not use
those calls as fa
Original Message
Subject: Re: [sane-devel] Git repositories are up
From: Jeff Kowalczyk
To: sane-devel at lists.alioth.debian.org
Date: 05/04/2009 01:58 PM
>
> Are the ssh:// urls for committers only?
>
> Should users and packagers use the http:// url forms?
>
Yes and yes.
Original Message
Subject: [sane-devel] Git repositories are up
From: Julien BLACHE
To: SANE Mailing List
Date: 05/04/2009 12:02 PM
>
> I guess I'm waiting for questions now? :) (and flames?)
>
Good work! I hope to build a Win32 package now that you have this
running offici
Original Message
Subject: Re: [sane-devel] sane runs in windows without cygwin
From: Michael Cronenworth
To: m. allan noah
CC: sane-devel at lists.alioth.debian.org
Date: 01/15/2009 09:15 AM
>
> OK, I wanted to reply before people thought I posted and ran. I'm c
Original Message
Subject: Re: [sane-devel] sane runs in windows without cygwin
From: m. allan noah
To: Michael Cronenworth
CC: sane-devel at lists.alioth.debian.org
Date: 01/14/2009 08:25 AM
> 2009/1/13 Michael Cronenworth :
>> If anyone is interested in the changes
Hello,
I've had success in building sane with MinGW, MSYS, and
libusb-win32-0.12. During my initial work I was unable to find much of
anything about such a feat as most people settled for Cygwin.
Some caveats:
1. I ripped out all backends except for "fujitsu" as this is the scanner
I have. The
26 matches
Mail list logo
