Can't open data file in r14202

David Reiser dbreiser at earthlink.net
Wed May 31 22:17:24 EDT 2006


On May 31, 2006, at 7:39 PM, Chris Shoemaker wrote:

> On Wed, May 31, 2006 at 05:57:22PM -0400, David Reiser wrote:
>>
>> On May 31, 2006, at 1:22 PM, Derek Atkins wrote:
>>
>>> Chris Shoemaker <c.shoemaker at cox.net> writes:
>>>
>>>>> Yes, my ltmain.sh has the line.
>>>>>
>>>>
>>>> Any news on this front?  Maybe we should ask some libtool folks for
>>>> some help.
>>>
>>> Are you sure that a shared object is still supposed to be called
>>> ".so" on Mac?  Are you sure this isn't a glib/gmodule bug?
>>
>> loadable modules (as opposed to shared libraries) can have any
>> extension. Apple recommends .bundle, but the world at large seems to
>> prefer .so.
>>
>
> Yes, and AFAICT, .so has worked for a long time.  We've verified that
> libtool is correctly building a shared module.  It's just the
> unconventional .dylib extension that's a problem.  So either:
>
> a) new libtools changed the convention (unlikely); or
>
> b) something about your setup is causing libtool to name shared
> modules .dylib; or
>
> c) something about our use of libtool is wrong.
>
> But I don't know what c) would be, since it's building the correct
> file, and the extension is something libtool is supposed to hide from
> us.
>
>> The fink folk have some information:
>>
>>   http://fink.sourceforge.net/doc/porting/shared.php
>>
>> I'm hoping that's enough to answer chris' initial questions
>>
>
> That's a helpful document for understanding how it's _supposed_ to
> work, but it doesn't tell me what's wrong.

I started a thread in fink-devel:  http://thread.gmane.org/ 
gmane.os.macosx.fink.devel/12837/focus=12837

In addition to the first pointer to the fink docs, there has been  
some additional info:

 From David Morrision:
"Another useful fact, not mentioned on that page:  these days, libtool
and its autoconf friends can automatically name bundles as .so files
if they are set up properly.  Perhaps Peter O'Gorman can give some
advice on this."

So Chris is on the right track, I just have to find the right  
incantation.

And from Peter O'Gorman:
"Gnucash has a whole bunch of libraries that are also loadable modules
and is one of the reasons that dlcompat got written all those years ago.
Gnucash-1.8 and 1.9 may differ in this regard though, I do not know.

1.8 always uses libltdl or guile to load modules, and guile always uses
it's own libltdl, libltdl has a hard-coded-at-compile-time idea of what
the loadable module extension is, and depending on the libtool version,
that will either be .so or .dylib on darwin. This should not matter if
the .la files are kept around though, as the .la file has the dlopenable
name in it.

gnucash-1.9 probably still uses libltdl to open modules, doesn't it?"

But that is a bit strange, because I do have the .la file around.



>
> Just for kicks: Please go into src/backend/file, do a 'make clean' and
> then a 'make'.  Then, post the line from the output that contains the
> ".libs/libgnc-backend-file.dylib" string.
>
> Thanks.
>
> -chris
>

--
David Reiser
dbreiser at earthlink.net



More information about the gnucash-devel mailing list