On Thu, Feb 26, 2009 at 10:07 PM, m. allan noah wrote:
> On Thu, Feb 26, 2009 at 11:00 PM, Chris Bagwell
> wrote:
> > m. allan noah wrote:
> >>
> >> On Thu, Feb 26, 2009 at 9:46 PM, Chris Bagwell
> >> wrote:
>
> > Here is an idea to explore... Is there any change your RPM package is
> > replaci
"m. allan noah" writes:
> On Thu, Feb 26, 2009 at 9:46 PM, Chris Bagwell
> wrote:
>> m. allan noah wrote:
>>>
>>> Actually chris asked for this previously, but it looks correct:
>>>
>>> ?/bin/sh ../libtool ? --mode=install /usr/bin/install -c
>>> 'libsane-fujitsu.la' '/usr/lib/sane/libsane-fuji
"m. allan noah" writes:
> On Thu, Feb 26, 2009 at 6:23 PM, Olaf Meeuwissen
> wrote:
>> "m. allan noah" writes:
>>
>>> On Sun, Feb 22, 2009 at 2:06 PM, Chris Bagwell
>>> wrote:
m. allan noah wrote:
>
> it's not just that it leaves the links behind, it actually makes the
> link
"m. allan noah" writes:
> On Sun, Feb 22, 2009 at 2:06 PM, Chris Bagwell
> wrote:
>> m. allan noah wrote:
>>>
>>> it's not just that it leaves the links behind, it actually makes the
>>> links to 1.0.19, even when 1.1.0 is also installed.
>>>
>> Couldn't find any documentation related to what l
Olaf Meeuwissen wrote:
> "m. allan noah" writes:
>
>
>
>> now i did, and yes- that is the culprit.
>>
>
> One should *not* run ldconfig on the directory holding the backends,
> ie ${sanelibdir}. Frontends should link against libsane which is in
> ${libdir}. If one absolutely insists on r
On Thu, Feb 26, 2009 at 11:00 PM, Chris Bagwell wrote:
> m. allan noah wrote:
>>
>> On Thu, Feb 26, 2009 at 9:46 PM, Chris Bagwell
>> wrote:
>>
>>>
>>> And just to be sure; did you also run the "ldconfig -n /usr/lib/sane"
>>> step
>>> to verify its not ldconfig doing the wrong thing?
>>>
>>
>> no
m. allan noah wrote:
> On Thu, Feb 26, 2009 at 9:46 PM, Chris Bagwell
> wrote:
>
>> And just to be sure; did you also run the "ldconfig -n /usr/lib/sane" step
>> to verify its not ldconfig doing the wrong thing?
>>
>
> now i did, and yes- that is the culprit.
>
Hmmm, seems maybe its al
On Thu, Feb 26, 2009 at 9:46 PM, Chris Bagwell wrote:
> m. allan noah wrote:
>>
>> Actually chris asked for this previously, but it looks correct:
>>
>> ?/bin/sh ../libtool ? --mode=install /usr/bin/install -c
>> 'libsane-fujitsu.la' '/usr/lib/sane/libsane-fujitsu.la'
>> /usr/bin/install -c .libs/
> Just tried to reproduce this. ?Configured 1.0.19 and the CVS snapshot
> of 2009-02-26 with --prefix=/tmp/sane, built and installed.
> Installing the snapshot over 1.0.19 results in:
>
> ?-rwxr-xr-x 1 olaf olaf ? ?875 2009-02-27 10:21 libsane-fujitsu.la
> ?lrwxrwxrwx 1 olaf olaf ? ? 24 2009-02-27
m. allan noah wrote:
> Actually chris asked for this previously, but it looks correct:
>
> /bin/sh ../libtool --mode=install /usr/bin/install -c
> 'libsane-fujitsu.la' '/usr/lib/sane/libsane-fujitsu.la'
> /usr/bin/install -c .libs/libsane-fujitsu.so.1.1.0
> /usr/lib/sane/libsane-fujitsu.so.1.1.0
On Thu, Feb 26, 2009 at 6:23 PM, Olaf Meeuwissen
wrote:
> "m. allan noah" writes:
>
>> On Sun, Feb 22, 2009 at 2:06 PM, Chris Bagwell
>> wrote:
>>> m. allan noah wrote:
it's not just that it leaves the links behind, it actually makes the
links to 1.0.19, even when 1.1.0 is also i
On Sun, Feb 22, 2009 at 2:06 PM, Chris Bagwell wrote:
> m. allan noah wrote:
>>
>> On Fri, Feb 20, 2009 at 3:08 PM, Chris Bagwell
>> wrote:
>>
>>>
>>> When backend was converted to automake, it uses the standard automake
>>> support to install libraries. ?That does install symlinks on fresh
>>> i
Chris Bagwell writes:
> m. allan noah wrote:
>> On Sun, Feb 22, 2009 at 2:16 PM, Chris Bagwell
>> wrote:
>>
>> Yes- i can confirm that it works as expected on top of a
>> vendor-packaged 1.0.19, except for one problem:
>>
>> /usr/lib/sane/libsane.so.1 -> libsane-xerox_mfp.so.1.1.0
>>
>> Look
Chris Bagwell wrote:
>> /usr/lib/sane/libsane.so.1 -> libsane-xerox_mfp.so.1.1.0
>>
>> Looks like we picked up the last backend and made an extra symlink for
>> it? I have installed fedora 10's rpm too, so perhaps that made the
>> symlink as well?
>
> Hmmm, thats back? It was a "feature" o
On Sun, Feb 22, 2009 at 2:16 PM, Chris Bagwell wrote:
> Hmm, I did notice one interesting thing. I went ahead and re-installed
> sane-1.0.19 back on top of the pre-existing private directory that had both
> 1.0.19 and 1.1.0-cvs installed.
>
> sane-1.0.19's libtool did overwrite all symlinks (bas
m. allan noah wrote:
> On Sun, Feb 22, 2009 at 2:16 PM, Chris Bagwell
> wrote:
>
>> Re-installing CVS points *everything* back to 1.1.0 so.
>>
>
> Yes- i can confirm that it works as expected on top of a
> vendor-packaged 1.0.19, except for one problem:
>
> /usr/lib/sane/libsane.so.1 -> l
Chris Bagwell wrote:
> Couldn't find any documentation related to what libtool behaviour
> should be in tihs area.
>
> I just now installed sane 1.0.19 tarball into a private directory and
> then installed current CVS on top of it. The behaviour I got seems to
> be the behaviour you want. In t
m. allan noah wrote:
> On Fri, Feb 20, 2009 at 3:08 PM, Chris Bagwell
> wrote:
>
>> When backend was converted to automake, it uses the standard automake
>> support to install libraries. That does install symlinks on fresh install.
>>
>> I think your point is that now if a user installs, libs
Chris Bagwell wrote:
Hi,
> libsane2.so.0.0.0). We don't want to move libsane.so to libsane.so.2.0.0
> blindly or else will break a lot of applications that were working fine.
The .so symlink is only used at link time, not at runtime, so...
JB.
--
Julien BLACHE
On Fri, Feb 20, 2009 at 3:08 PM, Chris Bagwell wrote:
>
>
> On Fri, Feb 20, 2009 at 12:38 PM, m. allan noah wrote:
>>
>> I'm not sure, but i think the build system used to overwrite all the
>> .so and .so.1 symlinks. It no longer does. I think this is a useful
>> feature, because you can tell use
Hmmm, I was going to add it back in but I noticed 1) the old CVS code
was probably broken and 2) the old CVS code was probably doing what the
comment said and only creating symlinks for missing symlinks (I hadn't
noticed the "test ! -f $${file}" before). It doesn't appear to be
fixing symlink
OK, I'll add the old symlink logic back in.
Chris
On Fri, Feb 20, 2009 at 12:38 PM, m. allan noah wrote:
> I'm not sure, but i think the build system used to overwrite all the
> .so and .so.1 symlinks. It no longer does. I think this is a useful
> feature, because you can tell users just to build from source and they
> will be using the new vers
I'm not sure, but i think the build system used to overwrite all the
.so and .so.1 symlinks. It no longer does. I think this is a useful
feature, because you can tell users just to build from source and they
will be using the new version. Otherwise, they have to uninstall the
old version, and this
24 matches
Mail list logo
