From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "carlo\.bramix" Newsgroups: gmane.lisp.guile.devel Subject: Re: MinGW build fixes Date: Sat, 27 Jun 2009 12:22:59 +0200 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1246098198 32657 80.91.229.12 (27 Jun 2009 10:23:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Jun 2009 10:23:18 +0000 (UTC) To: "guile-devel" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Jun 27 12:23:11 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MKV3u-0005B4-Ev for guile-devel@m.gmane.org; Sat, 27 Jun 2009 12:23:11 +0200 Original-Received: from localhost ([127.0.0.1]:55390 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKV3t-000204-Bv for guile-devel@m.gmane.org; Sat, 27 Jun 2009 06:23:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MKV3p-0001zz-Nk for guile-devel@gnu.org; Sat, 27 Jun 2009 06:23:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MKV3l-0001zk-R4 for guile-devel@gnu.org; Sat, 27 Jun 2009 06:23:05 -0400 Original-Received: from [199.232.76.173] (port=37404 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKV3l-0001zh-KQ for guile-devel@gnu.org; Sat, 27 Jun 2009 06:23:01 -0400 Original-Received: from cp-out1.libero.it ([212.52.84.101]:47016) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKV3l-000596-4O for guile-devel@gnu.org; Sat, 27 Jun 2009 06:23:01 -0400 Original-Received: from libero.it (192.168.17.2) by cp-out1.libero.it (8.5.107) id 4A44A5BD000BC179 for guile-devel@gnu.org; Sat, 27 Jun 2009 12:22:59 +0200 X-Sensitivity: 3 X-XaM3-API-Version: 4.3 (R1) (B3pl25) X-SenderIP: 79.40.68.237 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8783 Archived-At: Hello! >> I don't understand why this fixes anything, since the `_ptr' variables= >> are declared as `SCM_API' just like the non-`_ptr' variables. > > Indeed. My guess is that it's because the DLL import/export mechanism > works for atomic data - i.e. chars, ints, pointers etc - but not for > structs. False. A DLL can export functions, variables, structures, unions and classes. After few fixes that I'm preparing to share, guile already compiles and i= t works perfectly in cygwin, which uses DLL too: although it virtualizes= a lot, cygwin cannot do miracles, it's always windows based and if you a= dd -mno-cygwin it becames identical to mingw. What we could suspect about it is the implementation of -export-dynamic u= nder your mingw: which version are you using? I'm using the latest maintenance releases of gcc 3.4.5 and binutils 2.18.= 50 without troubles. Actually the troubles with mingw are elsewhere... may I ask how you made = it working? Unless it has been committed recently, guile cannot be even compiled well= because it is missing the support for CreateFileMapping(), plus other fi= xes around the code! Are you using another posix compatibility layer? But I could not see any = change in your patch for configure script... Anyways, I would not corrupt guile because an isolated compiler bug (my o= pinion). Sincerely, Carlo Bramini. ---------- Initial Header ----------- >From : guile-devel-bounces+carlo.bramix=3Dlibero.it@gnu.org To : ludo@gnu.org Cc : guile-devel@gnu.org Date : Sat, 27 Jun 2009 10:29:54 +0100 Subject : Re: MinGW build fixes > ludo@gnu.org (Ludovic Court=E8s) writes: > > >> SCM_API struct scm_t_cell_type_statistics scm_i_master_freelist; > >> +SCM_API struct scm_t_cell_type_statistics *scm_i_master_freelist_pt= r; > >> SCM_API struct scm_t_cell_type_statistics scm_i_master_freelist2; > >> +SCM_API struct scm_t_cell_type_statistics *scm_i_master_freelist2_p= tr; > > > > I don't understand why this fixes anything, since the `_ptr' variable= s > > are declared as `SCM_API' just like the non-`_ptr' variables. > > Indeed. My guess is that it's because the DLL import/export mechanism > works for atomic data - i.e. chars, ints, pointers etc - but not for > structs. Or at least, not in the same way - it could be that some > extra magic incantation is needed somewhere. > > (For example, there's no problem with scm_cells_allocated, which is > also referenced by the inline scm_cell code.) > > I haven't managed to find a reference for this, though. Also this > restriction could be one imposed by MSVC/Windows, or it could be a > restriction in MinGW's emulation of that. > > I guess the thing to do would be to email the MinGW people, so I'll do > that. > > > Also, it adds an indirection, which may impact performance. > > Yes. So I guess I should make these diffs #ifdef __MINGW32__. > > > Other than that, I think this is good news! > > Me too. On the one hand Windows isn't a free platform, so it can't be > our prime concern. On the other, I think it's good for us to grow the > possible audience for Guile as much as possible. > > (Guile is already in Cygwin, of course, but it's an older version and > AFAIK the build was not straightforward. So these fixes are about > making Windows builds work out of the upstream box.) > > Regards, > Neil > > >