Hi All, I'm just getting started with Homebrew, so please forgive me for not knowing more. :-) I've installed Homebrew at /usr/local in line with the instructions: > mkdir homebrew > curl -L http://github.com/mxcl/homebrew/tarball/master | tar xz --strip 1 -C homebrew I've then used it to install couchdb: > brew install couchdb This appears to work until I run the CouchDB Test Suite via the Futon interface -- Running the test suite leads to lots of failures. Googling the errors leads to an exact matching problem with a fix: http://www.mail-archive.com/user@couchdb.apache.org/msg05922.html > >>> Can you run the couchjs binary on the command line? > >>> > >>> Something like: > >>> > >>> $ couchjs /usr/local/share/couchdb/server/main.js > >>> > >>> And then type ["reset"] and hit enter. If that fails can you paste the > >>> output? > >>> > >>> Paul Davis > >> > >> > >> This is what I get: > >> > >> macinjosh:~ Josh$ couchjs /usr/local/share/couchdb/server/main.js > >> dyld: Library not loaded: Darwin_DBG.OBJ/libjs.dylib > >> Referenced from: /usr/local/lib/couchdb/bin/couchjs > >> Reason: image not found > >> Trace/BPT trap > >> > >> - Josh > >> > >> > > > > Did you happen to follow the instructions for building Spidermonkey > > that say to use DYLD_LIBRARY_PATH? I'd suggest symlinking the library > > and headers into /usr/local/[include|lib] to see if that fixes your > > issue. There are instructions at [1] under the "Avoiding > > DYLD_LIBRARY_PATH" section. After you fix that, you'll probably need > > to re-configure and re-build couchdb. > > > > Paul Davis > > > I created the symlinks and recompiled couchdb without the > -with-js-[include|lib] flags and the Test Suites runs smoothly now. > > Thanks. > > - Josh Trying the same trick of running couchjs I get a very similar problem: > $ cd '/usr/local/homebrew/Cellar/couchdb/0.10.1/share/couchdb/server/' > $ couchjs main.js > dyld: Library not loaded: libmozjs.dylib > Referenced from: /usr/local/homebrew/Cellar/couchdb/0.10.1/lib/couchdb/bin/couchjs > Reason: image not found > Trace/BPT trap So I assume that if I could implement the fix we'd be good to go. (I noticed Spidermonkey being installed with couchdb...) My trouble is I don't know: 1. What the DYLD_LIBRARY_PATH is and where to symlink it to. 2. How to recompile within the homebrew context. Any and all help would be very much appreciated! TIA Carlton
Update. I've got a fix of sorts but I'm not happy with it. If anyone can explain the consequences of my actions I'd be grateful... On 2 Mar 2010, at 14:38, Carlton Gibson wrote: > I've installed Homebrew at /usr/local in line with the instructions: > >> mkdir homebrew >> curl -L http://github.com/mxcl/homebrew/tarball/master | tar xz --strip 1 -C homebrew > > I've then used it to install couchdb: > > This appears to work until I run the CouchDB Test Suite via the Futon interface -- Running the test suite leads to lots of failures. Goo gling the errors leads to an exact matching problem with a fix: > > http://www.mail-archive.com/user@couchdb.apache.org/msg05922.html >> > Did you happen to follow the instructions for building Spidermonkey >> > that say to use DYLD_LIBRARY_PATH? I'd suggest symlinking the library >> > and headers into /usr/local/[include|lib] to see if that fixes your >> > issue. There are instructions at [1] under the "Avoiding >> > DYLD_LIBRARY_PATH" section. After you fix that, you'll probably need >> > to re-configure and re-build couchdb. It turns out that this is a known issue with installing CouchDB with a prefix (as homebrew does). There's a workaround described here: http://issues.apache.org/jira/browse/COUCHDB-562 But I have to admit I didn't understand how I would be able to modify the homebrew formula in order to implement this myself. As such I went for the emergency approach of symlinking the dylibs as described above: $ ln -s /usr/local/homebrew/lib/* /usr/local/lib This works -- The CouchDB test suite runs without any errors. However, it totally breaks the encapsulation of the Homebrew build. I have kept a list of the new symlinks to make sure I remove them as soon as possible but I'm left wondering what issues I've exposed myself to later... Can anyone help with a way of modifying the formula so that this workaround isn't needed? TIA! Regards, Carlton
Your problem is you didn't install to /usr/local and couchdb dynamically loads libjs rather than linking to it at compile time. The solution is indeed to amend the DYLD_LIBRARY_PATH environment variable. The homebrew solution would be to add this to the couchdb start up script. On Tue, Mar 2, 2010 at 4:33 PM, Carlton Gibson <carlton.gibson@noumenal.co.uk> wrote: > Update. I've got a fix of sorts but I'm not happy with it. If anyone can > explain the consequences of my actions I'd be grateful... > On 2 Mar 2010, at 14:38, Carlton Gibson wrote: > > I've installed Homebrew at /usr/local in line with the instructions: > > mkdir homebrew > > curl -L http://github.com/mxcl/homebrew/tarball/master | tar xz --strip 1 -C > homebrew > > I've then used it to install couchdb: > This appears to work until I run the CouchDB Test Suite via the Futon > interface -- Running the test suite le ads to lots of failures. Goo gling > the errors leads to an exact matching problem with a fix: > http://www.mail-archive.com/user@couchdb.apache.org/msg05922.html > >> Did you happen to follow the instructions for building Spidermonkey >> that say to use DYLD_LIBRARY_PATH? I'd suggest symlinking the library >> and headers into /usr/local/[include|lib] to see if that fixes your >> issue. There are instructions at [1] under the "Avoiding >> DYLD_LIBRARY_PATH" section. After you fix that, you'll probably need >> to re-configure and re-build couchdb. > > It turns out that this is a known issue with installing CouchDB with a > prefix (as homebrew does). > There's a workaround described here: > http://issues.apache.org/jira/browse/COUCHDB-562 > But I have to admit I didn't understand how I would be able to modify the > homebrew formula in order to implement this myself. > As such I went for the emergency approach of symlinking the dylibs as > described above: > $ ln -s /usr/local/homebrew/lib/* /usr/local/lib > This works -- The CouchDB test suite runs without any errors. > However, it totally breaks the encapsulation of the Homebrew build. I have > kept a list of the new symlinks to make sure I remove them as soon as > possible but I'm left wondering what issues I've exposed myself to later... > Can anyone help with a way of modifying the formula so that this workaround > isn't needed? > TIA! > Regards, > Carlton
On 2 Mar 2010, at 17:26, Max Howell wrote: > Your problem is you didn't install to /usr/local and couchdb > dynamically loads libjs rather than linking to it at compile time. > > The solution is indeed to amend the DYLD_LIBRARY_PATH environment variable. > > The homebrew solution would be to add this to the couchdb start up script. What about the part of the ticket that talks about the RPATH stuff? This isn't another install_name_tool fail, is it? -- Cheers, Mike Arthur http://mikearthur.co.uk
Hi Guys, Thanks for the input. On 2 Mar 2010, at 17:59, Mike Arthur wrote: > On 2 Mar 2010, at 17:26, Max Howell wrote: > >> Your problem is you didn't install to /usr/local and couchdb >> dynamically loads libjs rather than linking to it at compile time. >> >> The solution is indeed to amend the DYLD_LIBRARY_PATH environment variable. >> >> The homebrew solution would be to add this to the couchdb start up script. > > What about the part of the ticket that talks about the RPATH stuff? This isn't another install_name_tool fail, is it? Given that the Homebrew docs make a virtue of keeping everything within the Homebrew namespace, and given that the default `brew install couchdb` installs CouchDB somewhere other than /usr/local, the formula SHOULD adjust the dynamic library path to the correct value without the user having to put in place questionable symlinks or hack the startup script. (The force of the SHOULD here is just, "What a newbie would expect having read the documentation"; I suspect that other senses of 'should' apply but I'm new here. :-) Via Twitter @CouchDB pointed me to the --with-js-* options to the ./configure command. Looking at the couchdb.rb formula it seems that this could easily be added to the install method. If I work out what the command needs to say, would somebody be able to look at my suggested amendment to the formula and quickly talk me through the process of submitting it back? Thanks again, Carlton
> Given that the Homebrew docs make a virtue of keeping everything within the Homebrew namespace, and given that the default `brew install couchdb` installs CouchDB somewhere other than /usr/local, the formula SHOULD adjust the dynamic library path to the correct value without the user having to put in place questionable symlinks or hack the startup script. Indeed, it's a bug. Homebrew would be pretty pointless if nothing worked after install. Although the docs do recommend installing to /usr/local. This is the default. And if you had, you wouldn't have experienced this bug. > Via Twitter @CouchDB pointed me to the --with-js-* options to the ./configure command. Looking at the couchdb.rb formula it seems that this could easily be added to the install method. If I work out what the command needs to say, would somebody be able to look at my suggested amendment to the formula and quickly talk me through the process of submitting it back? Please create a ticket, fork, push and link to your branch on the ticket. We'll merge at the earliest opportunity.
On 3 Mar 2010, at 09:53, Max Howell wrote: > Although the docs do recommend installing to /usr/local. This is the > default. And if you had, you wouldn't have experienced this bug. I'm a bit confused about what you mean here, i.e. whether the referent of each of "docs" and "default" is CouchDB's or Homebrew's -- however, don't worry. > Please create a ticket, fork, push and link to your branch on the > ticket. We'll merge at the earliest opportunity. I will do so. Thanks again. Carlton
> Although the docs do recommend installing to /usr/local. This is the > default. And if you had, you wouldn't have experienced this bug. > > I'm a bit confused about what you mean here, i.e. whether the referent of > each of "docs" and "default" is CouchDB's or Homebrew's -- however, don't > worry. The Homebrew docs suggest /usr/local. You installed to /usr/local/homebrew. Now I'm guessing this was an error based on a misunderstanding, but the curl line that we provide does it right, and I'm guessing you did some "homebrew" download and untar thing instead. I'm rewriting all the docs at the moment anyway taking into account stuff like this, so hopefully things will improve. > Please create a ticket, fork, push and link to your branch on the > ticket. We'll merge at the earliest opportunity. > > I will do so. Great, we'll merge the fix quickly, thanks for the detective work.
On 3 Mar 2010, at 11:40, Max Howell wrote: > The Homebrew docs suggest /usr/local. You installed to > /usr/local/homebrew. Now I'm guessing this was an error based on a > misunderstanding, but the curl line that we provide does it right, and > I'm guessing you did some "homebrew" download and untar thing instead. Ah, okay -- this wasn't clear (to me at least) -- looking at the Install instructions again I'd say the preferred installation method should be first. :-) I think I'll follow the steps to uninstall and start again... Regards, Carlton
>> Your problem is you didn't install to /usr/local and couchdb >> dynamically loads libjs rather than linking to it at compile time. >> >> The solution is indeed to amend the DYLD_LIBRARY_PATH environment variable. >> >> The homebrew solution would be to add this to the couchdb start up script. > > What about the part of the ticket that talks about the RPATH stuff? This isn't another install_name_tool fail, is it? Probably not seeing as it's a dlopen() thing. But I didn't read the ticket.