<daviid>working on a guile-gnome release, i get an error running make distcheck, anyone familiar with libtoo could give me some hint? here the error: <daviid>/bin/sed: can't read /usr/lib/x86_64-linux-gnu/libcairo.la: No such file or directory <daviid>libtool: link: `/usr/lib/x86_64-linux-gnu/libcairo.la' is not a valid libtool archive <daviid>Makefile:505: recipe for target 'libgw-guile-gnome-cairo.la' failed <davexunit>daviid: sorry, not familiar with that error. <daviid>indeed that file does not exist, but libcairo.a and libcairo.so are there exist <daviid>would it be a libtool problem, it does not seem to have anythig to do with guile-gnome, which runs make fine <mark_weaver>some distros (including debian I believe) don't like .la files. they may have patched up their libtool to inhibit creation of them. <daviid>mark_weaver: i remember about that , what should i do? ah ok, will talk to civodul, in the mean time trying to look for solution on the web <daviid>it seems to be in our Makefile(s).am <daviid>./gnome/gw/Makefile.am:guilegnomelib_LTLIBRARIES = libgw-guile-gnome-cairo.la <daviid>surely guile add the same problem <daviid>no, what i just wrote here above is not the problem <daviid>if i look for occurrences of libcairo, in the entire guile-gnome tree, i can only find 1 occurrence, in ./guile-gnome-platform-2.16.3/_build/cairo/gnome/gw/libgw-guile-gnome-cairo.la <daviid>this file is generated by debian libtool (?!), here is the top of the file: "Generated by libtool (GNU libtool) 2.4.2 Debian-2.4.2-1.11" <daviid>dependency_libs=' -L/opt/lib /opt/lib/libguile-cairo.la /usr/lib/x86_64-linux-gnu/libcairo.la -lcairo-gobject -lcairo /opt/lib/libgwrap-guile-runtime.la -lrt /opt/lib/libgwrap-core-runtime.la /usr/local/src/guile-gnome/git-clone/guile-gnome-platform-2.16.3/_build/glib/gnome/gobject/libguile-gnome-gobject-2.la -lgobject-2.0 -lgthread-2.0 -lglib-2.0 /opt/lib/libguile-2.0.la -lffi -lunistring -lgmp /usr/lib/x86_64-linux-gnu/libltdl.la -ldl <mark_weaver>we should probably run distcheck on a GNU Guix system, since it will have newer versions of the autotools to bootstrap from. <daviid>where as it knows there is no libcairo.la file <daviid>i'm very weak about the tool chain, but why[how] would debien libtool create this libcairo.la dependency if it 'rejects' since a while now? mistery for me <mark_weaver>my hypothesis might be wrong. this is a weak area for me. please ask civodul. <daviid>mark_weaver: i will don't worry. and even if, i really wish to solve and therefore be independent as of being able to release guile-gnome guile-clutter whithout requiring other people... ***Sgeo is now known as wtf8
<daviid>mark_weaver: fi, libtool is a script generated by the configure step [i thought if was a libtool package script], which is the case for guile as well. so i tried copying the libtool script from guile, thinking it was in a better stage, but it leads to the same error [which means maintainers do not [and prob never did] distcheck on debian] <nobody111>I'm trying to define a new smob type in a C lib code. According to the info example "Defining New Types (Smobs)", at some point , one allocates memory for the smob struct using a call such as "scm_new_smob (smob_tag, ptr_to_smob_type)". But, this call causes a compiler warning that I later traced to file "smob.h", where scm_new_smob is declared with both arguments of "scm_t_bits" type. This clashes with the definition in the in <nobody111>fo documentation where the second argument is of type void*. <sneek>nobody111, you have 1 message. <nobody111>so, is info documentation and example wrong? Or, it is safe to perform void* to scm_t_bits conversion? <daviid>heya civodul! would you mind trying to give me some hint, i'm facing a problem with guile-gnome, make distcheck, on debian, it creates dependencies to *.la 'official' [from debian packages] that do not exists, such as libcairo.la <civodul>daviid: without looking into more detail, i know that Debian removes .la files from all its packages <civodul>this is probably not very helpful for libtool users <amirouche>nobody111: that said, people here, told me dynamic bindings are better way to go, and from what I've see "not that bad" ;) <civodul>daviid: does /usr/lib/x86_64-linux-gnu/libcairo.la exist at all? <daviid>yes, the problem is we create these files, and i'm toolchain weak, i don't know where exactly <daviid>no, as you said, no more .la files on debian, but libcairo.a and libcairo.so <daviid>i digged quite a lot already but satill can't find which script of ours do generate these lib*.la names which trigger the bug <daviid>and this only happens with distcheck, so in guile-gnome-platform-2.16.3/_build/* tree <nobody111>yes, dynamic bidings are nice, but when you want to interface C libs and you do it directly in Scheme, it's kind like you are C-coding in scheme. I prefer to confine uglier C stuff to a C code and the bind it via function calls and few SMOBS to Scheme. <amirouche>nobody111: you mean that you have some C-ish stuff to do before doing the scheme thing? <daviid>civodul: during make distcheck on the cairo sub directory, then [and only then] this file is created: <daviid>./guile-gnome-platform-2.16.3/_build/cairo/gnome/gw/libgw-guile-gnome-cairo.la <nobody111>i'm dealing with libraries that have special functions to allocate and release memory. i simply don't like exporting them to Scheme, when I can wrap that crap at C-level of things. <daviid>which contyains this dependency: <amirouche>nobody111: some thing that I needed to figure, the smob pointer can be any pointer... at first I was wrapping every wiredtiger structure in dummy typedef struct { WT_FOO * wt_FOO } my_foo; it's of course not necessary <daviid>./guile-gnome-platform-2.16.3/_build/cairo/gnome/gw/libgw-guile-gnome-cairo.la:dependency_libs=' -L/opt/lib /opt/lib/libguile-cairo.la /usr/lib/x86_64-linux-gnu/libcairo.la -lcairo-gobject -lcairo /opt/lib/libgwrap-guile-runtime.la -lrt /opt/lib/libgwrap-core-runtime.la /usr/local/src/guile-gnome/git-clone/guile-gnome-platform-2.16.3/_build/glib/gnome/gobject/libguile-gnome-gobject-2.la -lgobject-2.0 -lgthread-2.0 -lglib-2.0 <daviid>/opt/lib/libguile-2.0.la -lffi -lunistring -lgmp /usr/lib/x86_64-linux-gnu/libltdl.la -ldl -lcrypt -lm -lgc' <amirouche>nobody111: another thing, C function that are declared to be scheme procedure must return something, a "scheme function" can not have a signature liek "void my_functino(SCM thing, SCM other)" <amirouche>nobody111: if you don't care about the return value return SCM_UNSPECIFIED (check the manual) <nobody111>amirouche, did you use this function from FFI maybe? make-pointer address [finalizer] <daviid>civodul: in the Makefile.am of the cairo/gnome/gw subdir, i can read this <daviid>guilegnomelib_LTLIBRARIES = libgw-guile-gnome-cairo.la <daviid>but i can not find, nowhere i the entire tree any "lib*.la" occurence, so i don't know where official lib*.la comes from <daviid>i ment lib*.la for occicial libraries, we do build ours, apparently, with the la extension <daviid>so my quiz is for any guilers expert in the toolchain: where and what should I change so that our *.la generated files do _not_ try anythibg but linking to what is on the system used to make distcheck ? <amirouche>nobody111: I'm not using dynamic ffi at all, the only thing somewhat related I use are bytevectors that I build in scheme then pass to C code, bytevectors are contigous memory of bytes, it helps a lot. it's something like struct { char[] * data; int size } <nobody111>Guys/Girls, lets assume there you have pointers to memory that is outside of Guile memory management system. How do you let Guile know about it, and how do you help Guile remove this memory when the objects in use are not longer needed? Can you do this through FFI 'make-pointer' function? <daviid>in case it may help, here is the Makefile.am for cairo: <nalaginrut>nobody111: if it's allocated outside Guile without gc_malloc, you have to make sure it's freed outside Guile, <sneek>Welcome back nalaginrut, you have 1 message. <nobody111>nalaginrut, so what is the "finalizer" function that is passed to make-pointer for, then? <nobody111>i thought, if i pass a free function to make-pointer, then Guile might call this when it wants to garbage collect the pointer and thus free the memory <nalaginrut>nobody111: 'finalizer' allow you to pass a C function to free the pointer <nalaginrut>it's what I mean 'free it outside Guile', since it's C function <nobody111>ok, good. So, how do I let Guile know how much memory did i allocate outside Guile? Presumably, this would allow it to plan when to release the memory. <nalaginrut>hmm...let me reconsider it, seems I missed something <nalaginrut>well, you don't have to know the size if you just want to free it <nobody111>of course, this means Guile still hasn't got a clue about how much mem did i allocate <nalaginrut>but if you reference a pointer from a thirdparty lib, maybe you can't get the size <nalaginrut>Guile can't detect it automatically, actually, any platform can't do it IMO <nobody111>in my case, i have special malloc and free routines, so i know how much memory it is. i just need to let guile know it <nobody111>sure, sure, but i thought there is a way to let Guile know: "this object has this much memory. however, call my special 'free' when you want to garbage collect it." <nalaginrut>maybe you can use cons, rather than write a smob, (cons pointer size) <nobody111>i want to avoid to manually call free, i'd rather leave that to guile, if it can handle this <nalaginrut>if you don't need the size, I think you can do it without any wrapper <saul>Are there any users of VIM paredit here? <saul>If I use M-W on the expression (foo bar) it produces ((foo bar)) . I am wondering if there is an easy way to go the other direction -- i,e., remove the parenthesis surrounding a list. <mark_weaver>saul: there is such a thing in emacs paredit, but I've never looked at VIM paredit (didn't even know it existed) <amirouche>it's way better to auto-closing parens, it feels like the 12-button mouse key of gamers but for the schemer ;) <amirouche>saul: sorry I though you were talking about emacs <saul>amirouche, that's alright. VIM paredit is a little bit crippled compared to Emacs paredit, but I think it is mostly that it doesn't duplicate VIM's builtin functionality. <saul>(and the documentation for VIM paredit is suboptimal). <saul>It would probably be more apprehensible for me if I were a VIM expert. <cky>I can't wait for guile-emacs to be mainlined. It'd be cool to port paredit to Scheme. :-) <daviid>soory if these are stupid quizz, but make distclean does not remove the distdir and tarball, is this normal? also, the distdir, like guile-gnome-platform-2.x.xx in 'my' case is created with perms "dr-xr-xr-x", (c) is this expected ? it forces me to chmod -R ...; rm -rf ... just curious <daviid>actually, i still want to resolve the problem, now that i started i'm curious to solve it, but i wonder, in theory, we should not even need a libcairo dependency, since guile-gnome depends on guile-cairo, not cairo directly <cky>daviid: What is your umask? <cky>I think if it comes out with r-xr-xr-x, that means your umask was 0222 instead of 022 or 002. <civodul>daviid: libgw-guile-gnome-cairo.la is a wrapper around .libs/libgw-guile-gnome-cairo.so, which is generated as shown in the log you pasted <civodul>so you said that /usr/lib/x86_64-linux-gnu/libcairo.la doesn't exist, right? <civodul>normally libtool will only try to use .la files that actually exist <daviid>there is no more .la files on debian <daviid>civodul: yewsterday i tried the libtool script from guile then i even tried the libtool script from debian, none worked <civodul>so i wonder why libtool translated "-lcairo" in "/usr/lib/x86_64-linux-gnu/libcairo.la" here <civodul>could you try to run "make LDFLAGS=--verbose"? <daviid>i don't know either :lo: and just said, i even try s sum link tp /usdr/bin/libtool <daviid>ok of course i can, right now :) <daviid>let me just clean my mess attempting all sort of things, 2 seconds ... <civodul>(it's not /usr/bin/libtool that's used, it's $top_builddir/libtool) <daviid>right, i moved that file and made a symbolic link so it used the debian 1 <civodul>it's a bad idea because Debian's version may be a different one, and probably a patched one <daviid>ok, i just tried, but back to normal now. did run make LDFLAGS=--verbose <daviid>civodul: guile-gnome's libtool script is generated, might be worth you look at it ? i can paste <civodul>hmm --verbose doesn't show anything more <daviid>ok for libtool paste, too bad the verbose stuff... <civodul>maybe check that $top_builddir/libtool isn't too different from an unmodified 'libtool' script from GNU <daviid>i tried copying the one from guile, it fails as well <daviid>never tried make distcheck on guile-cairo itself, it should fail as well i presume <daviid>just in case it trigger something <civodul>it would also make sense to check ltmain.sh, just in case <daviid>ltmain.sh, don't have that in $top_builddir <daviid>no diff at all with the 1 from guile <daviid>oh, too bad, you're our bet libtool chain expert, haha so now i'm lost <daviid>guile-cairo makedistcheck fails with because of a test-suite ]never run distcheck before it appears...] <daviid>so no help from that side either <civodul>just in case there are stale files around, you could run "make distclean && autoreconf -vfi && ./configure && make" <civodul>and see if the libcairo.la issue still comes up <daviid>hum, ever since i try, i do git clean -dxf <daviid>the make works perfectly fine, it is the make distcheck that does not <daviid>that libcairo.la issue only occurs at distcheck <daviid>too bad rlb isn't around, he might have an idea? <daviid>civodul: i have to leave for a little whilw, but bbl, if you have an idea talk to sneek :)