| Time |
S |
Nick |
Message |
| 19:24 |
|
chris |
morning |
| 19:27 |
|
aindilis |
morning |
| 19:34 |
|
fbcit |
morning |
| 19:34 |
|
fbcit |
gmcharlt around? |
| 19:34 |
|
gmcharlt |
hi fbcit |
| 19:35 |
|
fbcit |
I'm having problems getting XML::LibXSLT to build |
| 19:35 |
|
fbcit |
but it may be pathing issues with the way Makefile.PL tests for the presence of -xslt |
| 19:36 |
|
gmcharlt |
so it's not generating a Makefile? |
| 19:36 |
|
fbcit |
no it fails on the test for -xslt |
| 19:36 |
|
gmcharlt |
what ultimately matters is whether the C compiler can find, so if you can fake out Makefile.PL to get a Makefile, that might be enough |
| 19:37 |
|
fbcit |
good idea, I'll try that route. |
| 19:39 |
|
fbcit |
I think the real issue with Makefile.PL's tests resides in syntactic diffs between make and dmake.... |
| 19:43 |
|
gmcharlt |
looking at how its Makefile.PL is try to test for -lxslt, I can easily see it |
| 19:45 |
|
fbcit |
rather complicated it seems to me |
| 19:45 |
|
fbcit |
got a Makefile |
| 19:46 |
|
fbcit |
but still have some issues with missing libs/includes |
| 20:04 |
|
fbcit |
I am having a problem generating a def file from libxslt.dll w/pexports |
| 20:05 |
|
fbcit |
errors out for some reason, but does generate a def file |
| 20:05 |
|
fbcit |
I suppose theres a chance that the resulting .a library is defective. |
| 20:09 |
|
gmcharlt |
maybe -- test suite should indicate whether or not it's defective |
| 20:09 |
|
fbcit |
gmcharlt: http://www.emmestech.com/softw[…]-0.43/moron1.html |
| 20:09 |
|
fbcit |
seems there may be a bit more to doing the conversion from dll to static |
| 20:53 |
|
fbcit |
gmcharlt: looks like pexports is dieing before grabbing a complete list of functions from libxslt.dll |
| 20:54 |
|
fbcit |
the functions the complier can't find are also missing from the def file created by pexports |
| 02:21 |
|
fbcit |
u around gmcharlt ? |
| 02:23 |
|
gmcharlt |
hi fbcit |
| 02:30 |
|
fbcit |
gmcharlt: question |
| 02:30 |
|
gmcharlt |
ok |
| 02:30 |
|
fbcit |
I had a brainstorm |
| 02:31 |
|
fbcit |
I finished out the definition file by adding the functions dmake complained about |
| 02:31 |
|
fbcit |
then rebuild the static lib |
| 02:31 |
|
fbcit |
this worked...almost |
| 02:31 |
|
fbcit |
I have some syntax like the following |
| 02:31 |
|
fbcit |
undefined reference to `_nm__xsltLibxsltVersion |
| 02:32 |
|
fbcit |
where xsltLibxsltVersion is in the lib |
| 02:32 |
|
fbcit |
but not _nm__foo |
| 02:32 |
|
fbcit |
so I tried adding this to the def file: |
| 02:32 |
|
fbcit |
_nm__xsltLibxsltVersion = xsltLibxsltVersion |
| 02:32 |
|
fbcit |
but that did not help |
| 02:32 |
|
fbcit |
any thoughts? |
| 02:33 |
|
gmcharlt |
fbcit: at first glance the _nm__ prefix seems to be some sort of linker name mangling |
| 02:35 |
|
fbcit |
early in the compilation I get: Info: resolving _xsltMaxDepth by linking to __imp__xsltMaxDepth (auto-import) |
| 02:35 |
|
gmcharlt |
does putting in just the _nm__ name work? |
| 02:35 |
|
fbcit |
no, I tried that too |
| 02:35 |
|
fbcit |
later I get: nmth000003.o: undefined reference to `_nm__xsltMaxDepth' |
| 02:36 |
|
fbcit |
so your probably correct about the name mangling |
| 02:36 |
|
gmcharlt |
the underlying library is a C library, not a C++ library, right? |
| 02:37 |
|
fbcit |
I think it is c++ as we call g++ to compile rather than gcc ? |
| 02:38 |
|
gmcharlt |
I wonder if use of g++ instead of gcc in the Makefile is the problem |
| 02:38 |
|
gmcharlt |
the name mangling is a C++ism |
| 02:39 |
|
fbcit |
I'll try changing it |
| 02:41 |
|
fbcit |
no diff compiling w/gcc |
| 02:59 |
|
gmcharlt |
fbcit: about time -- their notion of November was getting a little stretched :) |
| 03:01 |
|
fbcit |
:) |
| 03:02 |
|
fbcit |
I also notice that the individual in charge of releasing it observer that pexports borks (to use a kados term) on libxslt... |
| 03:02 |
|
fbcit |
not a good sign |
| 03:03 |
|
gmcharlt |
no; my googling has been finding the same thing |
| 03:03 |
|
gmcharlt |
on the other hand, if you solve it, you become an instant hero :) |
| 03:10 |
|
fbcit |
just fired an email off to the XML::LibXSLT author as he has some notes in his README on Win32 compilation |
| 03:14 |
|
fbcit |
looking through the cpan tests for this module, it appears that no one has attempted to install and test on Win32 |
| 03:16 |
|
gmcharlt |
*sigh* |
| 03:18 |
|
fbcit |
right, especially since it looks like we're within three refs of having it compile |
| 03:18 |
|
fbcit |
though it may not test out even then |
| 03:24 |
|
gmcharlt |
fbcit: I won't have much time to look at this until Thursday or Friday (dealing with other Koha issues), but if you could send me your notes on libxslt so far, I'd appreciate it |
| 03:29 |
|
fbcit |
gmcharlt: sure thing |
| 03:34 |
|
kados |
akk! |
| 03:34 |
|
kados |
fbcit: seriously? |
| 03:35 |
|
fbcit |
according to the Readme it is not *that* difficult... |
| 03:35 |
|
fbcit |
using mingw |
| 03:36 |
|
kados |
ahh |
| 04:03 |
|
gmcharlt |
fbcit: any joy? |
| 04:05 |
|
fbcit |
nah |
| 04:05 |
|
fbcit |
include problems... path issues again... |
| 04:06 |
|
fbcit |
seems we cannot locate xmlmemory.h even though it is in the path |
| 04:07 |
|
gmcharlt |
oh well, tomorrow is another day (for me, at least, I'm going to bed) -- good night |
| 04:08 |
|
fbcit |
I'm not too far behind. g'night |
