Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "Ralf Habacker" To: Subject: RE: cygipc (and PostgreSQL) XP problem resolved! Date: Sat, 10 May 2003 16:30:35 +0200 Message-ID: <006401c31700$b80a56b0$0a1c440a@BRAMSCHE> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <20030510105420.GE19367@cygbert.vinschen.de> > > With qt I have a similar problem. The current release was build with > > cygwin-1.3.20. Currently it is not possible to link a qt > application with recent > > cygwin release due to type problems. > > > > header - QTextStream::QTextStream( FILE *, int mode ) > > > > used - QTextStream::QTextStream(__sFILE64 *, int) > > Huh? That's correct. What's the exact problem with this? The application > (or DLL) shouldn't worry about the actual implementation of FILE*. > The problem is that in c++ functions signatures are mangled into the symbol name. The cygwin-1.3.20 builded qt dll exports the above mentioned function (and all other with FILE* types parameter) with the symbol "__11QTextStreamP7__sFILEi", while compiling a qt application with current cygwin release refers to "__11QTextStreamP7__sFILE64i", which is definitly not available in the dll. At the time I recognized this, I assumed, that this is caused by the ongoing implementation process. Today I have analysed this a little more and found that newlib enables this the sFILE64 as default. newlib/libc/include/sys/config.h #if defined(__CYGWIN32__) || defined(__CYGWIN__) #define __FILENAME_MAX__ (260 - 1 /* NUL */) #define _READ_WRITE_RETURN_TYPE _ssize_t #define __LARGE64_FILES 1 #define __CYGWIN_USE_BIG_TYPES__ 1 I think at least for a specific migration time there should be a compatibility define (for example __CYGWIN_NO_BIG_TYPES__) to ensure, that c++ applications based on older packages could be build. Currently I can't see, if this is all to do, so please see this as a basic proposal. #if defined(__CYGWIN32__) || defined(__CYGWIN__) #define __FILENAME_MAX__ (260 - 1 /* NUL */) #define _READ_WRITE_RETURN_TYPE _ssize_t #ifndef __CYGWIN_NO_BIG_TYPES__ # define __LARGE64_FILES 1 # define __CYGWIN_USE_BIG_TYPES__ 1 #else # define __LARGE64_FILES 0 # define __CYGWIN_USE_BIG_TYPES__ 0 #endif Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/