X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqAEAIpUKFKhbwoQ/2dsb2JhbABbgzzCF4E+dIIkAQEFOEABEAsYCRYPCQMCAQIBRRMBBwEBF4dVAw8MsRQXiRuPYAeEHQOUG4UJhH2LOoE6gWg
X-IPAS-Result: AqAEAIpUKFKhbwoQ/2dsb2JhbABbgzzCF4E+dIIkAQEFOEABEAsYCRYPCQMCAQIBRRMBBwEBF4dVAw8MsRQXiRuPYAeEHQOUG4UJhH2LOoE6gWg
Message-ID: <52285593.7080208@imb-cnm.csic.es>
Date: Thu, 05 Sep 2013 11:57:39 +0200
From: Francesc Vila <francesc DOT vila AT imb-cnm DOT csic DOT es>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: geda-user AT delorie DOT com
CC: Kai-Martin Knaak <knaak AT iqo DOT uni-hannover DOT de>
Subject: Re: [geda-user] Any new geda port for Windows?
References: <8738y3iigd DOT fsf AT dome DOT home> <kd22k1$vna$1 AT ger DOT gmane DOT org> <kd4557$3gn$1 AT ger DOT gmane DOT org> <201301151848 DOT r0FIm62T000949 AT envy DOT delorie DOT com> <kd8n3i$qcq$1 AT ger DOT gmane DOT org>
In-Reply-To: <kd8n3i$qcq$1@ger.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: geda-user AT delorie DOT com

On 17/01/13 12:25, Kai-Martin Knaak wrote:
> DJ Delorie wrote:
>
>>> @DJ: Can you initiate a new build?
>> gaf-gaf.o:gaf.c:(.text+0xba): undefined reference to `_setenv'
> You mean, the automatic build fails due to this error?
> I didn't find a bug report for this on launchpad.
> Anyone looking into this already? Is this a hard issue?
>
> ---<)kaimartin(>---
>
For anyone interested, I managed to compile gEDA 1.8 (1.9 does not work 
for me, but similar changes apply) using mxe.cc, and it seems that is 
working correctly.

I had to make some changes, though (and probably are difficult to apply 
upstream in a portable way):

  - gEDA 1.8 does not have gaf executable, so there is no issue with the 
_setenv symbol. (on 1.9 changing to g_setenv solves the issue).
  - In order to be able to load guile (and I think because mxe compiles 
guile statically), libgeda has to statically link against srfi-1-v-3 
module (and probably srfi-60 too, but it is not necessary). I found the 
solution on 
http://old.nabble.com/statically-linking-in-srfi-modules-td34998581.html. Below 
are the changes I applied:

--- a/libgeda/src/libgeda.c
+++ b/libgeda/src/libgeda.c
@@ -31,6 +31,9 @@
  #include <stdlib.h>
  #endif

+#include <libguile.h>
+#include <guile/srfi/srfi-1.h>
+
  #include "libgeda_priv.h"
  #include "libgeda/libgedaguile.h"

@@ -38,6 +41,25 @@
  #include <dmalloc.h>
  #endif

+static SCM init_srfi_1(void)
+{
+  scm_init_srfi_1 ();
+  return SCM_UNSPECIFIED;
+}
+/*
+static SCM init_srfi_60(void)
+{
+  scm_init_srfi_60 ();
+  return SCM_UNESPECIFIED;
+}
+*/
+static SCM bind_srfi_initializers(void *dummy)
+{
+  scm_c_define_gsubr ("%init-srfi-1", 0, 0, 0, init_srfi_1);
+  /*scm_c_define_gsubr ("%init-srfi-60", 0, 0, 0, init_srfi_60);*/
+  return SCM_UNSPECIFIED;
+}
+
  /*! \brief Perform runtime initialization of libgeda library.
   *  \par Function Description
   *  This function is responsible for making sure that any runtime
@@ -47,6 +69,9 @@
   */
  void libgeda_init(void)
  {
+  scm_c_call_with_current_module (scm_c_resolve_module ("guile"),
+                                  bind_srfi_initializers, NULL);
+
  #ifdef ENABLE_NLS
    /* Initialise gettext */
    bindtextdomain (LIBGEDA_GETTEXT_DOMAIN, LOCALEDIR);

Then , the Makefile.am files on gnetlist/src, gschem/src, gsymcheck/src, 
utils/gschlas have to add the path to libguile-srfi--srfi-1-v-3.la on 
LDADD variables, and on libgeda/src LIBADD variable.

Last, on share/guile/1.8/srfi/srfi-1.scm the load-extension call has to 
be changed to (%init-srfi-1).

With those changes, geda compiles correctly, but does not load. For 
reasons I do not understand I had to change the geda init scripts (the 
load call prepended again the base path). The changes are below:

diff  scheme/geda.scm scheme/geda.scm
38,41c38,41
<   (if (and (file-exists? (build-path geda-data-path scheme-dir))
<            (directory? (build-path geda-data-path scheme-dir))
<            (access? (build-path geda-data-path scheme-dir) R_OK))
<     (let ((dir (opendir (build-path geda-data-path scheme-dir))))
---
 >   (if (and (file-exists? scheme-dir)
 >            (directory? scheme-dir)
 >            (access? scheme-dir R_OK))
 >     (let ((dir (opendir scheme-dir)))
45,47c45,47
<           (if (and (regular-file? (build-path geda-data-path path))
<                    (has-suffix? (build-path geda-data-path path) ".scm")
<                    (access? (build-path geda-data-path path) R_OK))
---
 >           (if (and (regular-file? path)
 >                    (has-suffix? path ".scm")
 >                    (access? path R_OK))
diff  system-gafrc system-gafrc
114c114
< (load (build-path "print-colormap-darkbg")) ; dark background
---
 > (load (build-path geda-rc-path "print-colormap-darkbg")) ; dark 
background
121c121
< (define geda-confd-path "gafrc.d")
---
 > (define geda-confd-path (build-path geda-data-path "gafrc.d"))
diff  system-gschemrc system-gschemrc
35c35
< (load (build-path "gschem-colormap-darkbg")) ; dark background
---
 > (load (build-path geda-rc-path "gschem-colormap-darkbg")) ; dark 
background

With these changes, gEDA compiles and loads correctly. The last thing to 
change is the function s_slib_search_dirs on libgeda/src/s_slib.c. This 
function does not handle well when readdir returns a struct dirent with 
characters other than ASCII, so, in my system, I cannot descent to 
schematic. I have coded a quick replacement function using the winapi 
that solves the issue:

char *s_slib_search_dirs(const char *basename)
{
   int i;
   WIN32_FIND_DATA ffd;
   HANDLE hFind = INVALID_HANDLE_VALUE;
   DWORD dwError = 0;
   char *slib_path = NULL;
   char directory[MAX_PATH];
   int dirLen = 0;

   for (i = slib_index-1 ; i >= 0; i--) {
     dirLen = strlen(slib[i].dir_name);

     if (dirLen + 3 > MAX_PATH) {
       s_log_message ("Dir path too long\n");
       continue;
     }

     strncpy (directory, slib[i].dir_name, MAX_PATH);
     directory[dirLen] = '\\';
     directory[dirLen + 1] = '*';
     directory[dirLen + 2] = '\0';

     hFind = FindFirstFile(directory, &ffd);

     if (INVALID_HANDLE_VALUE == hFind) {
       s_log_message ("Invalid handle value\n");
       continue;
     }

     do {
       if (!(ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY))  {
         if (strcmp(ffd.cFileName, basename) == 0) {
           slib_path = g_strdup (slib[i].dir_name);
           s_log_message ("Returning %s\n", slib_path);
           FindClose(hFind);
           return slib_path;
         }
       }
     } while (FindNextFile(hFind, &ffd));

     dwError = GetLastError();

     if (dwError != ERROR_NO_MORE_FILES) {
       s_log_message ("FindNextFile error\n");
     }
   }

   FindClose(hFind);
   return NULL;
}

I know that the major part of the changes are quite dirty hacks, but it 
is the only way I found to use gEDA greater than 1.6 on windows. I have 
not tested thoroughly, but for me, it seems to work. If someone who has 
a deeper knowledge of gEDA sources wants to help me integrate this in a 
more portable way into 1.8 sources, I would be glad to help.

Regards,

Francesc