Perhaps sending the config.log file would help, although it appears
that since it finds xml2 and xslt, that it works fine. What I was
worried about was that you had compiled xml2 and xslt rather than using
the version that setup.exe installs - perhaps there is some patch that
they made to the package to get it to have the proper dll exports,
which is not in the version you compiled.
On Oct 10, 2004, at 3:55 AM, Paul Forgey wrote:
I tried updating my cygwin installation after reading your reply,
which updated automake and libtool-devel. I rebuilt from scratch
again after the update.
I haven't made any progress at all. I'm telling the configure scripts
to put the libraries and headers into
/GNUstep/System/Library/Libraries and /GNUstep/System/Library/Headers
(with executables and dlls into /GNUstep/System/Tools). With this
setup, the configure script is able to detect libxml2 and xslt just
fine. I built libxslt-1.1.11 and libxml2-2.6.14. Oh, libxml2 wants
to put the dll in --/Libraries/bin. Proably a quick hack for windows
which works with the prefix is /usr or /usr/local. Moved the dll into
Tools and adjusted libxml2.la appropriately.
setting LDFLAGS=/usr/local/lib isn't a valid linker option. Exactly
what are you setting that to? -L/usr/local/lib? I tried re-doing all
this using LDFLAGS=-L/GNUstep/System/Library/Libraries (and remembered
to export it) but I ended up with the exact same results. Also note
that, as per my followup post, I appear to be having this same issue
from gnustep-base when building gnustep-gui if I use --disable-xml to
postpone this and build gnustep-base. So I'm not certain this problem
is specific to libxml2/libslt or how those particular libraries are
being built.
It seems to me the problem is how cygwin or the GNUstep
configure/build process, or both is/are mishandling the screwed up
shared library architecture windows has (m$ never did get their head
out of dos).
I can send you my config.status files if it would be any help.
"Adam Fedor" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
My Windows machine's a little slow, so it took me a while to do this
myself. I got a recent setup.exe from cygwin and installed the 1.5.11
cygwin DLL, xml2 2.6.13, xslt 1.1.10.
I did have one problem configuring - I had put ffcall in a
non-standard location, and configure gave an error says libxml2 did
not exist because of that (certainly a bug in configure that I need
to fix), but after I did something like
LDFLAGS=/usr/local/lib ./configure
it worked fine. I then compiled and installed base and ran some test
programs with no problems.
Have you made any progress on this? It's possible compiling things
yourself causes weird problems that one might not get otherwise.
On Oct 2, 2004, at 9:59 PM, Paul Forgey wrote:
Yes, thanks!
Now that I'm past that, it's screwing up elsewhere. The libxml2 and
libxslt which cygwin provides don't seem to get along with gnustep,
so I uninstalled them and built libxml2-2.6.14 and libxslt-1.1.11.
Individually, they both build and install fine. The configure for
gnustep-base finds them OK too.
However, now when attempting to link the base library, none of
libxml2's symbols seem to be available that are needed from libxslt.
/GNUstep/System/Library/Libraries/
libxslt.a(transform.o)(.text+0x59): In function `templPush':
/cygdrive/c/users/paulf/src/gnustep/libxslt-1.1.11/libxslt/
transform.c:106: undefined reference to `_xmlRealloc'
/GNUstep/System/Library/Libraries/
libxslt.a(transform.o)(.text+0x73):/
cygdrive/c/users/paulf/src/gnustep/libxslt-1.1.11/libxslt/
transform.c: 111: undefined reference to `_xmlGenericErrorContext'
[ and thousands more ]
Info: resolving _xmlFree by linking to __imp__xmlFree (auto-import)
collect2: ld returned 1 exit status
dllwrap: gcc exited with status 1
make[2]: *** [shared_obj/gnustep-base.dll] Error 1
make[1]: *** [libgnustep-base.all.library.variables] Error 2
make: *** [internal-all] Error 2
"Adam Fedor" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
On Oct 2, 2004, at 4:20 AM, Paul Forgey wrote:
Running cygwin 1.5.11-1 and trying to build gnustep-base 1.10.0,
I'm running into the following build error. It's failing because
there is no occurance of "_class_name_" in the resulting list.
What exactly is the build process attempting to do? I see
_class_name_ in the nm output, but not if I filter it with the
first grep statement. I do, however, see quite a few symbols
starting with ___objc_class_name_ with a 'U' instead. Does this
mean for some reason the definitions are never actually being
built?
cat win32-def.top > libgnustep-base.def
nm [long list of objects] | grep '^........ [T] _' | sed
's/[^_]*_//'
> _tmp.def
Would it work if you used 'R' instead of 'T' in the grep statement?
Different versions of mingw/cyginw seems to work differently in
this respect, so it's hard to see how to solve that problem.
_______________________________________________
Help-gnustep mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/help-gnustep
_______________________________________________
Help-gnustep mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/help-gnustep
_______________________________________________
Help-gnustep mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/help-gnustep
