Mail Archives: geda-user/2013/09/05/05:58:22
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
- Raw text -