IRC channel logs

2013-10-30.log

back to list of logs

<fangism>the above guile seg-fault on snarf-check-and-output-texi does NOT occur on powerpc-darwin8 (apple-gcc-4.0.1 -O2 -g)
<fangism>but, it still does occur with clang-release-3.3 on x86_64-darwin11 (not Apple's)
<fangism>on OS X 10.7
***mario-go` is now known as mario-goulart
<davexunit>good evening, guilers
<davexunit>I'm looking for some thoughts. I'm currently reading SICP section 3.3. It's about a constraint solving system. http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html#%_sec_3.3
<davexunit>If you scroller down to the implementation of "adder", you'll see that it is implemented using some primitive dispatching method.
<davexunit>since I have not encountered Guile code written in this manner ever, I'm wondering how this would be done in a more "modern" style.
<davexunit>another example is the implementation of 'make-connector' here: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_%_sec_Temp_397
<davexunit>My inclination would be to use a SRFI-9 record type.
<ZombieChicken>Is there a webpage that covers good schemes for Lisp formatting?
<ZombieChicken>and no, that wasn't meant as a pun
<davexunit>ZombieChicken: http://mumble.net/~campbell/scheme/style.txt
<ZombieChicken>davexunit: Are there any alternatives?
<davexunit>ZombieChicken: probably, but that's a *the* style guide that I see cited.
<ZombieChicken>I see it has a listing of rational. That is always good to see. Thank you for the link
<davexunit>you're welcome.
<cky>I agree with davexunit that that's pretty much as official as it gets.
<davexunit>looks like I let a stray "a" into my sentence back ther.e
<davexunit>s/ther.e/there/
<davexunit>guess I just can't type tonight.
<ZombieChicken>That makes two of us. It takes me three tries to get a capital letter
<nalaginrut>morning guilers~
<davexunit>morning
<nalaginrut>o/
<systemovich>hi guys, the guile interpreter does not allow me to use the arrow keys. do you also experience this?
<systemovich>instead moving the cursor backwards when I press the left arrow, it prints ^[[D.
<madsy>systemovich: Happens when you don't build guile with readline support, I believe
<cky>madsy: That's not enough. You also have to load the readline module.
<madsy>Ok, right
<madsy>I'm happily ignorant about that and use Geiser ;-)
<cky>systemovich: In your ~/.guile file, add these two lines: (use-modules (ice-9 readline)) (activate-readline)
<madsy>systemovich: Or you can use Geiser in emacs. Which is 1000% better than the vanilla REPL
<systemovich>thanks, guys. I added those lines to ~/.guile. Now arrows work. I will also check out Geiser.
<cky>:-D
<madsy>:-)
<systemovich>:-)
<nalaginrut>systemovich: you may try guile-colorized & (ice-9 readline) if you don't want to launch heavy Emacs ;-P
<systemovich>nalaginrut: thanks, I will check it.
<systemovich>when I try to install geiser in emacs, I get a [No match] error. I created a ~/.emacs file to add the marmalade repository: http://pastebin.com/GfHgKZ0d
<wingo>moin
<wingo>systemovich: you might want jao; he usually wakes up later, in a few hours
<systemovich>wingo: thanks.
*TaylanUB spontaneously becomes curious as to what happened to the unboxed-floats idea ...
<ksinkar>what is equivalent of trace from Common Lisp in Guile?
<TaylanUB>Maybe ,trace in the REPL, I'm not sure what trace in CL is.
<wingo>search the manual for trace
<ksinkar>TaylanUB: in CL if you are tracing a procedure, you can see the step by step execution of your procedure in the REPL as the procedure is executed
<ksinkar>trace seems to be like a special-form operator like defun, if, or etc
<ksinkar>you call it by (trace procedure name)
<ksinkar>wingo, TaylanUB: the ,trace is not similar to the CL trace at all
<wingo>ksinkar: please see the manual, there are many things there :)
<ksinkar>wingo: ok
<ksinkar>wingo: I am using the info guile reference, if that is what you mean by the manual
<wingo>yep
<nalaginrut>ksinkar: ,tr for short ;-P
<nalaginrut>oops sorry, seems it's not what you need
<systemovich>finally got geiser installed. autoindenting and paren highlighting is indispensable.
<wingo>indentation and paren highlighting are part of base emacs, fwiw
<wingo>systemovich: you should try paredit, if you haven't already
<systemovich>wingo, I tried installing paredit, but there were some compile errors.
<nalaginrut>just install it from Emacs
<systemovich>actually, just warnings.
<systemovich>paredit works in scratchpad, but not in geiser.
<nalaginrut>well, I never use geiser
<TaylanUB>fangism: I'm on OS X 10.7 and just built a freshly pulled stable-2.0, yielding 2.0.9.97-b1fe
<TaylanUB>No fancy options at all, just ./autogen.sh && ./configure --prefix="$HOME_USR" && gmake && gmake install
<TaylanUB>Oh sorry, make not gmake.
<TaylanUB>(The OS X native make, which is some gmake version.)
<TaylanUB>I have environment variables PKG_CONFIG_PATH and LD_LIBRARY_PATH set explicitly to pathes I know I want, and CPPFLAGS and LDFLAGS set such that they have -I and -L flags for the relevant pathes too, but none of that should be relevant to the segfaults you mention.
***add^_`` is now known as add^_
<TaylanUB>I'm using boehmgc 7.2d, libffi 3.0.13, libunistring 0.9.3, and gmp 5.0.5, all from MacPorts. Tell me if I forgot any big dependencies that could be relevant.
<TaylanUB> http://sprunge.us/eNMH output of my home-baked build script.
<wingo>TaylanUB: your compiler version is relevant, and which compiler you are using
<TaylanUB>I don't have CC or so set so it'd be the OS X 10.7 default one. "cc --version" says "Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)" "Target: x86_64-apple-darwin11.4.2" "Thread model: posix". I'm on some iMac model with a 3.1 GHz i5, I think it's the fore-last iMac version.
<TaylanUB>(Oh, it says "27 inch, Mid 2011".)
<TaylanUB>(And model identifier 12.2 when I dig around some more. Should really be irrelevant though I suppose.)
<wingo>i suspect we are doing something undefined with the tortoise-and-hare thing
<wingo>friggin c compilers
<ksinkar>wingo: this is what I am talking about. The documentation says that I should be able to use trace, but in reality I am not able to use it.
<wingo>if that is the case you may have found a bug.
<wingo>but you would have to be much more specific.
<ksinkar>wingo: sure, I would not only like to be specific about my bug, but would want to resolve it as well. I want to get started on guile development, but am not confident of my capabilities. Some mentoring might help.
<wingo>i don't have the time to mentor, sorry -- the best i can do is write documentation and fix bugs; my best attempt at that is in the manual.
<wingo>if something doesn't behave like the manual says it does, then you have found a bug, either in the code or in the manual.
<wingo>you should make sure you are looking at the version of the manual that corresponds to your guile, fwiw
<wingo>and that version should be 2.0.9
<ksinkar>wingo: the particular entry that I linked has been removed in the 2.0 docs but exists in the 1.8 docs
<ksinkar>I am surprised why it was removed
<wingo>ksinkar: in that case you should be reading the 2.0 docs :)
<wingo>there are equivalents there, but things have been moved around
<wingo>in general the tracing support is better in 2.0, not worse...
<wingo> http://www.gnu.org/software/guile/manual/html_node/Tracing-Traps.html#Tracing-Traps
<wingo> http://www.gnu.org/software/guile/manual/html_node/Profile-Commands.html#Profile-Commands
<ksinkar>wingo: thank you
<wingo>np :)
<bananagram>I can't find anything for sound in the manual
<bananagram>it's frustrating my stupid plans
<bananagram>how do you do sound?
<nalaginrut>bananagram: dunno, what about guile-2d?
<nalaginrut>it's a game engine I think
<davexunit>bananagram: sound... in the guile manual?
<davexunit>that's out of the domain of guile.
<nalaginrut>davexunit: not even in guile-2d?
<cky>nalaginrut: Is guile-2d a frontend for SDL? Because the name just suggests it's a framebuffer interface.
<davexunit>nalaginrut: guile-2d can do it. but you get an entire engine and need an X window open to do it.
<davexunit>cky: it's a layer over SDL, OpenGL, FreeImage, and other such libraries.
<mark_weaver>bananagram: take a look at guile-gstreamer
<mark_weaver>there may be other options as well, but that's the one I know of.
<davexunit>^ ah yes, forgot about this. that would be more suitable.
<nalaginrut>actually guile-2d means guile-2dengine
<bananagram>okay
<mark_weaver>davexunit: what does guile-2d use for sound?
<nalaginrut>ah yeah, it's wingo 's project IIRC
<nalaginrut>guile-gstreamer
<davexunit>mark_weaver: SDL_mixer
<wingo>that thing is broke
<mark_weaver>guile-gstreamer is broke?
<wingo>it's old, out of date, etc
<davexunit>sound stuff is *really* primitive right now, in guile-2d. haven't given it much love.
<bananagram>hm
<bananagram>I just need to play some tones
<mark_weaver>bananagram: well, the other thing is you can always use 'system' to run an external command.
<mark_weaver>wingo: what version of gstreamer are the guile binding for?
<mark_weaver>*bindings
<wingo>mark_weaver: barely 0.10
<wingo>there was never a stable release corresponding to 0.10 iirc
<wingo>i think i last worked on those bindings in 2005 or so :/
<wingo>and now 1.0 is the new thing, with a new abi, after ~8 years of stable 0.10
<mark_weaver>to my mind, keeping things like these bindings up to date is probably more important for average users than the RTL compiler is.
<wingo>hehe
<wingo>to each his own i guess ;)
<wingo>& her
<mark_weaver>oh course you should work on what's fun for you :)
<mark_weaver>and the RTL compiler is certainly important.
<wingo>imo it's the most important thing i can be working on right now, guile-wise
<mark_weaver>yes, especially since you're the only one who'd be likely to get it done.
<nalaginrut>hmm...what's guile-wise
<wingo>"related to guile"
<bananagram>invaluable wisdom
<mark_weaver>we're all volunteers here, and we do what we want, as it should be.
<mark_weaver>but that said, based on my conversations with guile users here, it's far more common that people are stuck because of lack of good bindings than because guile 2.0 is not fast enough.
<mark_weaver>I hope I can write these things without anyone feeling guilty about what they're doing or not doing, because that's really not intended at all.
<nalaginrut>what's the hackers way is "if you want something, go for it"
<wingo>sure
<nalaginrut>like I need a lisp-machine board, then I raised a project around my whole hackerspace to build one, plus the industrial guys
<wingo>nalaginrut: did you really? :)
<wingo>neat :)
<nalaginrut>blame it when you paid for it, the seller won't reject your blaming for the sake of your money
<nalaginrut>wingo: we're busy for that project these days, because it's very hard to make it all free, especially WIFI chip
<nalaginrut>but we try our best for that
<nalaginrut>even there's only confidential datasheet, we can release the detailed info into the driver code, which is the best way to open the info
<nalaginrut>but we just can't publish the datasheet
***FractalF1ve is now known as FractalFive
<mark_weaver>nalaginrut: atheros makes wireless chips that can be used with free software.
<mark_weaver>I'm not sure that's the case for all of their chips, but some of them are okay at least.
<nalaginrut>mark_weaver: nice taste, but we do pick Atheros AR6003
<nalaginrut>but interesting is we still lack of the opcode datasheet
<nalaginrut>it's closed
<mark_weaver>see http://www.fsf.org/news/ryf-certification-thinkpenguin-usb-with-atheros-chip
<mark_weaver>nalaginrut: anyway, it might be better to just provide a USB port with the intention of plugging wireless into USB.
<mark_weaver>because who knows how often you'll be able to produce new versions of your boards.
<nalaginrut>we have to choose a SDIO interface, but it seems ath9l which uses USB
<mark_weaver>this way, when your boards are old, you'll still be able to plug in a more recent wireless chip.
<mark_weaver>I say this as someone who has tried to keep using some very old hardware.
<nalaginrut>mark_weaver: we'll provide USB on extensional board
<mark_weaver>nalaginrut: okay
<nalaginrut>but we have to deal with core board at this time
<nalaginrut>well, I know there're many ideas in tech views
<nalaginrut>but if you try it for manufacture, there're less choice and many things are not control by engineers
<nalaginrut>anyway, this is the interesting point when you hack industry
<mark_weaver>well, if I were doing it, I'd probably put USB on the main board instead of built-in wireless, but it's your project :)
<nalaginrut>mark_weaver: yes, I can understand, but there're too much similar design
<nalaginrut>we want a very tiny core board, and provide various shields
<nalaginrut>for any interfaces you want
<nalaginrut>did I mention the very low cost purpose? ;-P
<nalaginrut>it has to be cheap enough for poor students
<mark_weaver>okay, but now anyone who wants USB will need to buy a second board. and pretty much everyone wants USB, because it opens up a huge array of cheap possibilities.
<dsmith-work>Much as I hate usb, I agreee.
<nalaginrut>there's only a scheme-VM on a very compacted hardware, so please not imagine it as powerful Linux, maybe the USB driver needs to be done in the next step
<nalaginrut>so all the design around the core board has to be selected carefully
<mark_weaver>a single USB port would allow people to cheaply add almost anything: wireless, wired, mass storage, sound I/O, serial I/O, etc, etc.
<nalaginrut>yes, iff you have Linux
<nalaginrut>OK, real hacker could write drivers themselves
<mark_weaver>oh, I see. you're writing an OS from scratch. okay.
<mark_weaver>well, have fun with that.
<nalaginrut>and we're under the suggestions from hardware engineers ;-)
<dsmith-work>Oi
<nalaginrut>well, just buy the extra board, it may contain everything ;-P
<nalaginrut>and you could hide it every where if you drop the extra board
<nalaginrut>;-D
<mark_weaver>so, basically you intend to create both the hardware and software for a new computer system from scratch?
<mark_weaver>well, the CPU and the OS, developed together from scratch.
<mark_weaver>is that right?
<nalaginrut>heh, actually I think you found my purpose ;-)
<nalaginrut>but it's my own purpose
<wingo>sounds like a learning experience :)
<wingo>don't lose yourself though!
<nalaginrut>others just think it's interesting to be involved with their good at
<nalaginrut>well, unfortunately I can't design CPU, maybe years later, I have to swallow the things I've learned these years
<nalaginrut>wingo: well, I'm not going to do every things, I just think about the architecture and find out proper guys for it
<nalaginrut>if there's no, just put it
<nalaginrut>;-P
<nalaginrut>you know, that's interesting
<nalaginrut>I call it 'hack the industry', about how to create a new computer system from scratch
<nalaginrut>which is practical and creative
<nalaginrut>nowadays we can try things with nearly zero cost
<civodul>Hello Guilers!
<nalaginrut>heya ludo
<wingo>hey ludo
<dsmith-work>Heya wingo, what's the good news?
<wingo>dsmith-work: not much, my bootstrap mostly worked but there are some primcalls that i need to fix
<wingo>and clean up a bunch of things
<wingo>been busy though, hacking on firefox today
<davexunit>small rant: I just can't get over the fact that both the standard ruby and python implementations have a global interpreter lock. thank you, guile, for being better than this.
<wingo>true, but we do have some nasty races as well...
<wingo>we need to do better in that regard
<davexunit>oh :(
<add^_>?
<wingo>davexunit: you've never run into them?
<add^_>races?
<davexunit>wingo: I don't think so. examples?
<wingo>it's easy to hork your system from a --listen repl
<davexunit>well yeah, but that's the nature of multi-threaded applications isn't it?
<wingo>i guess
<wingo>i wish we had a better story there
<davexunit>I ran into that with guile-2d.
<wingo>better data types, better concurrency, ...
<davexunit>mvars helped me out a lot.
<davexunit>the problem with the --listen repl is when the main thread is running some sort of long operation, in my case an unbounded update/render loop.
<davexunit>so, I wrote a cooperative repl server with mark_weaver's help.
<ijp>oink
<civodul>we really need contracts
<davexunit>what are those?
<ijp>civodul: stis has something like that, but I can't say I've used it
<davexunit>something like this? http://dlang.org/dbc.html
<ijp>think pre-post argument checking, but only done at module boundaries
<civodul>like what Racket has
<civodul>and also usable on record fields
***wingo_ is now known as wingo
<wingo>hackety hack
<fangism>TaylanUB, wingo: my library dependencies for guile-2.0.9 are similar (from fink) http://paste.lisp.org/display/139704#6
<fangism>if you suspect undefined behaviorisms of compiler optimizations, I wonder if ubsan might be able to catch it
<fangism>has anyone built guile-2.0.9 with a recent clang on x86_64-!darwin?
<serhart>fangism, i just built it
<fangism>serhart: no crashes during documentation generation? yesterday, i was dealing with a seg fault http://paste.lisp.org/display/139704
<serhart>nope
<serhart>i built it with homebrew
<ijp>I think people always get the wrong idea about why it fails there
<ijp>it's nothing to do with doc generation per se, it's just the first place the build guile is used
<fangism>right, the stacktrace in the paste shows where things really go wrong
<dsmith-work>heh. Might be good to have make spit out an info message at that point. "If the build fails here, it's probably becuse ..."
<wingo>maybe we should run a quick guile -c 1 before going on
<wingo>to test guile
<ijp>echo "1" > sanity-check.test
<anddam>hello
<anddam> http://www.gnu.org/software/guile/manual/html_node/Foreign-Libraries.html "Normally, library is just the name of some shared library file that will be searched for in the places where shared libraries usually reside, such as in /usr/lib and /usr/local/lib."
<anddam>is there a configuration option to set the paths in which libraries are searched?
<anddam>I'm not able to find it
<ijp>I think no
<ijp>or at least, not from within guile
<saul>anddam, check out out the man page for 'ld.so'.
<ijp>anddam: try setting your LD_LIBRARY_PATH
<anddam>I'm having issues with guile in macports, since all libraries are in a prefix that isn't /usr or /usr/local gschem from gEDA-gaf cannot load the library
<anddam>I'm on OSX
<anddam>I'd rather patch the guile build
<ijp>saul: man page? info page!
<anddam>ijp: that's very GNUish :-)
<anddam>IIRC info is the preferred way to access documentation in GNU, is that correct?
<saul>anddam, it is not preferred by me. :)
<ijp>(info "(libtool) Libltdl interface") ld_dlopen searches a user defined search path (which I suppose guile could expose) followed by LTDL_LIBRARY_PATH and then LD_LIBRARY_PATH
<saul>Nonetheless, I believe MacOS uses ELF binaries and uses ld.so .
<civodul>i don't think it's called ld.so, is it?
<ijp>saul: guile uses libltdl, which says it provides this interface. How the platfrom handles that is none of our concern
<anddam>the dynamic linker is dyld
<anddam>and binary objects are Mach-O
<ijp>I suppose I should correct what I said earlier, LD_LIBRARY_PATH is only on gnu systems
<anddam>no dyld has similare variables as well
<anddam>similar*
<mark_weaver>anddam: as ijp said, guile lets libltdl search for the libraries. On most POSIX systems, libltdl consults $LD_LIBARY_PATH and $LTDL_LIBRARY_PATH, but I'm not sure off hand if it does something different on OSX.
<mark_weaver>However, recent versions of Guile also manually search in $GUILE_SYSTEM_EXTENSIONS_PATH, if that's set.
<mark_weaver>though using that variable would be kind of a hack, and it's not documented.
<mark_weaver>anddam: a quick perusal in the libltdl sources suggest that on Darwin, the $DYLD_LIBRARY_PATH variable is consulted. that's probably your best bet.
<mark_weaver>anddam: the other thing you can do is to provide an absolute pathname, in which case it won't search at all.
<anddam>DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH were the "similar varibles" I was referring to
<anddam>I don't know libltdl, would a variable set at guile's build time be then hardcoded or are you suggesting to set the DYLD_* at runtime of the program that is being linked to libguile?
<mark_weaver>I don't see "DYLD_FALLBACK_LIBRARY_PATH" anywhere in the libtool-2.4.2 sources, but maybe a newer version has it, dunno.
<anddam>worth a try
<mark_weaver>anddam: no, it's at runtime when it's relevant.
<mark_weaver>when using the Guile Dynamic FFI, the DYLD_LIBRARY_PATH should be consulted at runtime.
<mark_weaver>specifically, it's consulted when 'dynamic-link' is called.
<anddam>not a good solution then
<mark_weaver>well, another option is to pass an absolute pathname to 'dynamic-link'.
<ijp>can you not setenv it from within your .guile (or rather the global equivalent whose name I forget)
<anddam>the point is that in the whole geda-gaf source (that is providing gschem that is having the linking issue) I cannot even find a "dynamic-link" instance
<anddam>that along with my blatantly ignorance about Scheme doesn't make this easy
<anddam>blatant*
<ijp>are you sure geda is using the system foreign stuff?
<mark_weaver>anddam: maybe it's being linked from C. maybe search for scm_dynamic_link?
<anddam>searched both dynamic-link and dynamic_link
<anddam>actually I just grepped the source tree, I assume that would be in plain text, is that right?
<mark_weaver>or perhaps it's calling lt_dlopen (from libltdl) directly.
<mark_weaver>yes, it would be plain text.
<anddam>this is what I'm tracing when the issue happens https://gist.github.com/anddam/7239498 in my case libraries are in /opt/local/lib
<anddam>due to the three calls I guess the "culprit" is line sys_lib_dlsearch_path_spec='/usr/local/lib /lib /usr/lib' in configure script, it's in darwin section
<mark_weaver>ah, okay, so that's guile itself looking for one of its libraries.
<mark_weaver>guile hardcodes the pathname where its extensions should be found directly in its own executable.
<mark_weaver>so something is going wrong there.
<mark_weaver>what version of guile is this?
<anddam>1.8.8
<mark_weaver>also: what --prefix are you passing to its configure script? and where are the dynamic libraries actually ending up?
<anddam>prefix is /opt/local, libraries are in /opt/local/lib
<anddam>it's default macports
<mark_weaver>well, none of us here use guile 1.8 anymore. it's no longer maintained. guile 2.0.x has been out for over 2.5 years. I'm not surprised that 1.8 doesn't support modern OSX well.
<anddam>ok, let me try 2.0.x
<anddam>2.0.9
<anddam>quite a leap
<mark_weaver>granted, I don't know for sure if geda supports 2.0.x yet or not.
<mark_weaver>I'll take a look at the old 1.8.8 code.
<anddam>thanks a lot
<mark_weaver>do you have your guile-1.8.8 build directory around?
<anddam>sure
<anddam>just wiped it while building 2.0.9 but I can build again in a couple minutes
<mark_weaver>anddam: I looked at the guile-1.8.8 code, and it doesn't appear to do anything but call libltdl. it makes no attempt to make sure that the guile install location is in the paths that libltdl look at.
<mark_weaver>so basically, with guile 1.8.8, you're at the mercy of libltdl's default behavior.
<anddam>ok, let's check libtool
<mark_weaver>the relevant bit is in libtool/libltdl/configure. search for DYLD_LIBRARY_PATH
<mark_weaver>and you'll find the bit relating to darwin
<mark_weaver>basically, the default system path is: /usr/local/lib /lib /usr/lib
<mark_weaver>and it also looks in $DYLD_LIBRARY_PATH
<mark_weaver>anddam: are you a geda developer?
<mark_weaver>well, I guess what I'm wondering is: are you just looking for a way to install a working geda on your OSX box, or are you working on an OSX installer for geda, or something like that?
<mark_weaver>(I ask because it will affect the advice I give you)
<anddam>mark_weaver: yes, I just noticed the darwin* stanza in libtool configure, it's reading shlibpath_var=DYLD_LIBRARY_PATH
<anddam>I'm willing to fix the gEDA port in macports
<anddam>not a geda developer
<mark_weaver>okay. do macports install pretty much all libraries in /opt/local/lib ?
<anddam>yes, in fact it has a policy of using only libraries provided by macports itself
<mark_weaver>because an expedient solution that comes to mind is to change the macports recipe for libtool, that patches that part of the configure script, to change that line to: sys_lib_dlsearch_path_spec='/opt/local/lib /usr/local/lib /lib /usr/lib'
<anddam>thanks, I just did that :-)
<anddam>I'm rebuilding after patching it in the portfile
<anddam>I did that in guile as well but it didn't affected the behavior
<anddam>then you told me guile was doing what libtool was doing so I jumped on that
<mark_weaver>okay, sounds good. fwiw, I'd leave "/usr/local/lib /lib /usr/lib" there too, just in case someone is depending on that too.
<anddam>I did that way
<mark_weaver>excellent!
<anddam>actually I was trying to have the configure script catch it from the env variable
<mark_weaver>it might be that there's a better way than patching 'configure', but I'm not an autoconf expert.
<mark_weaver>but the fact that it's not even the top-level configure script might make it trickier.
<mark_weaver>(the one in libltdl is probably the relevant one here)
<anddam>rebuilding guile on the new libtool, just in case
*photon scrolls up
<photon>anddam: glad you found help here. :)
<mark_weaver>anddam: btw, looking more closely at the code, this line in libltdl/configure is the important one: #define LT_DLSEARCH_PATH "$sys_dlsearch_path"
<mark_weaver>anddam: can you search for LT_DLSEARCH_PATH in libltdl/confdefs.h ?
<mark_weaver>and make sure it's right?
<anddam>y-ay! http://d.pr/i/Tt4q+
<anddam>ok
<mark_weaver>well, if it works, that's good enough I suppose :)
<anddam>indeed
<anddam>and I suppose confdefs.h is generated by configure
<mark_weaver>there might be a way to do this by passing an argument to configure, which would be a more future-proof solution.
<mark_weaver>yes it is.
<anddam>configuring now
<anddam>mark_weaver: I wish that was in configure --help
<mark_weaver>heh, I was just looking there too :)
<mark_weaver>well, I'll have to look at this later. but at least you have a solution that works for now :)
<anddam>indeed, thanks a lot
<mark_weaver>you're welcome!
<anddam>btw no confdefs.h here
<anddam>or libtool 2.4.2
<anddam>s/or //
<mark_weaver>sorry, I have to afk for a while. but it would only be there after libltdl/configure runs, which might not be until after the toplevel make runs (not sure off hand)
<mark_weaver>oh, hmm, I don't see it either in my built libtool dir.
<mark_weaver>well, again, I'll have to look at it later.
<anddam>no needs, thanks again