Re: [DNG] Digital camera management borked

[Dr. Nikolaus Klepp]

Am Donnerstag, 3. März 2016 schrieb Go Linux:
> On Wed, 3/2/16, Dr. Nikolaus Klepp  wrote:
> 
>  Subject: Re: [DNG] Digital camera management borked
>  To: dng@lists.dyne.org
>  Date: Wednesday, March 2, 2016, 4:22 PM
>  
> Am Mittwoch, 2. März 2016 schrieb Rob:
> >  Original Message 
> > Subject: Re: [DNG] Digital camera management borked
> > Local Time: March 2, 2016 9:59 pm
> > UTC Time: March 2, 2016 9:59 PM
> > From: nuisa...@protonmail.com
> > To: dng@lists.dyne.org
> >
> >
> >
> >  Original Message 
> > Subject: [DNG] Digital camera management borked
> > Local Time: March 2, 2016 8:50 pm
> > UTC Time: March 2, 2016 8:50 PM
> > From: goli...@yahoo.com
> > To: dng@lists.dyne.org
> >
> > I am having trouble finding a way to browse thumbnails of the photos on my 
> > old canon camera. gtkam couldn't access the camera. I installed my old 
> > favorite f-spot from wheezy (apparently not available in jessie), but it 
> > couldn't even see the camera. The only way I have been able to access the 
> > camera is through the thunar file manager at this address (which is in need 
> > of some translation):
> >
> > gphoto2://[usb:003,036]/DCIM/
> >
> > But no image browser can open the jpgs in the folders at that address. Gimp 
> > can load only one at a time. It's been frustrating. Thankfully images can 
> > be c/p from there.
> >
> > My guess is that lack of support is due to the fact that fewer people are 
> > using stand-alone cameras. Any suggestions how to get a browse 
> > functionality back on Devuan?
> >
> > golinux
> >
> >
> > Not being funny, have you tried switching the camera off then on again 
> > whilst it is connected to your pc. Then Camera/Add camera, auto-detect.
> > I have a canon SX40 that requires this procedure occasionally.
> > Rob
> >
> > *in gtkam*
> 
> And maybe the camera has an option in the USB settings for "mass storage".
> 
> Nik
> 
> 
> 
> 
> Good one!  I never thought of that.  I don't use the camera often and mostly 
> it is still a mystery to me.  If I can find the manuals, I'll look into that. 
>  But then it has worked just fine with different apps over the years . . .

As did mine. And then a genius of an udev developer took care of it and made 
sure that the cameras ID_TYPE changed from "disk" to "generic", so no user but 
root could use the camera. Now it works again, but ...

Nik


-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Digital camera management borked

[Go Linux]

On Wed, 3/2/16, Dr. Nikolaus Klepp  wrote:

 Subject: Re: [DNG] Digital camera management borked
 To: dng@lists.dyne.org
 Date: Wednesday, March 2, 2016, 4:22 PM
 
Am Mittwoch, 2. März 2016 schrieb Rob:
>  Original Message 
> Subject: Re: [DNG] Digital camera management borked
> Local Time: March 2, 2016 9:59 pm
> UTC Time: March 2, 2016 9:59 PM
> From: nuisa...@protonmail.com
> To: dng@lists.dyne.org
>
>
>
>  Original Message 
> Subject: [DNG] Digital camera management borked
> Local Time: March 2, 2016 8:50 pm
> UTC Time: March 2, 2016 8:50 PM
> From: goli...@yahoo.com
> To: dng@lists.dyne.org
>
> I am having trouble finding a way to browse thumbnails of the photos on my 
> old canon camera. gtkam couldn't access the camera. I installed my old 
> favorite f-spot from wheezy (apparently not available in jessie), but it 
> couldn't even see the camera. The only way I have been able to access the 
> camera is through the thunar file manager at this address (which is in need 
> of some translation):
>
> gphoto2://[usb:003,036]/DCIM/
>
> But no image browser can open the jpgs in the folders at that address. Gimp 
> can load only one at a time. It's been frustrating. Thankfully images can be 
> c/p from there.
>
> My guess is that lack of support is due to the fact that fewer people are 
> using stand-alone cameras. Any suggestions how to get a browse functionality 
> back on Devuan?
>
> golinux
>
>
> Not being funny, have you tried switching the camera off then on again whilst 
> it is connected to your pc. Then Camera/Add camera, auto-detect.
> I have a canon SX40 that requires this procedure occasionally.
> Rob
>
> *in gtkam*

And maybe the camera has an option in the USB settings for "mass storage".

Nik




Good one!  I never thought of that.  I don't use the camera often and mostly it 
is still a mystery to me.  If I can find the manuals, I'll look into that.  But 
then it has worked just fine with different apps over the years . . .
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Digital camera management borked [solved]

[Go Linux]

On Wed, 3/2/16, Rob  wrote:

 Subject: Re: [DNG] Digital camera management borked
 To: "dng@lists.dyne.org" 
 Date: Wednesday, March 2, 2016, 3:59 PM
 
 >  Original Message 
> Subject: Re: [DNG] Digital camera management borked
> Local Time: March 2, 2016 9:59 pm
> UTC Time: March 2, 2016 9:59 PM
> From: nuisa...@protonmail.com
> To: dng@lists.dyne.org
>
>
>>  Original Message 
>> Subject: [DNG] Digital camera management borked
>> Local Time: March 2, 2016 8:50 pm
>> UTC Time: March 2, 2016 8:50 PM
>> From: goli...@yahoo.com
>> To: dng@lists.dyne.org
>>
>> I am having trouble finding a way to browse thumbnails of the photos on my 
>> old canon camera. gtkam couldn't access the camera. I installed my old 
>> favorite f-spot from wheezy (apparently not available in jessie), but it 
>> couldn't even see the camera. The only way I have been able to access the 
>> camera is through the thunar file manager at this address (which is in need 
>> of some translation):
>>
>> gphoto2://[usb:003,036]/DCIM/
>>
>> But no image browser can open the jpgs in the folders at that address. Gimp 
>> can load only one at a time. It's been frustrating. Thankfully images can be 
>> c/p from there.
>>
>> My guess is that lack of support is due to the fact that fewer people are 
>> using stand-alone cameras. Any suggestions how to get a browse functionality 
>> back on Devuan?
>>
>> golinux
>>
>>
> Not being funny, have you tried switching the camera off then on again whilst 
> it is connected to your pc. Then Camera/Add camera, auto-detect.
> I have a canon SX40 that requires this procedure occasionally.
> Rob
>
>
> *in gtkam*



Good suggestion, Rob.  I tried that with gtkam and f-spot before I posted.  
Devuan/xfce recognized the camera but the apps either couldn't find it or 
couldn't access it when they did.  FWIW, working with a camera on USB has 
always been roulette.  

And Mitt . . . I used to use Shotwell on squeeze then at some point it got 
totally borked.  I spent weeks on the shotwell list trying to figure out how to 
fix it.  Shotwell is also out of the running IMO because of it's allegiance to 
the gnome way of doing things.  That became very obvious from my interactions 
on the ML.  Eventually, I moved on to f-spot which is still working on my old 
squeeze.  I never used wheezy that much so can't remember what I was using 
there.

golinux 


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OT: Assembly resources

[Rainer Weikusat]

Emiliano Marini  writes:
> Maybe the C compiler adjusts what registers to use for C code to avoid
> conflicts, or saves his registers on the stack before the assembly code.
> I'm just guessing, I never embed assembly code in C programs.

When using gcc inline assembly, one will usually either use named
parameters and get the compiler to allocated registers for them based on
"parameter property specifications" or one will have to specifiy certain
registers as 'clobbered' by an inline asm.

>
> On Wed, Mar 2, 2016 at 7:17 PM, Hendrik Boom  wrote:
>
>> On Wed, Mar 02, 2016 at 08:55:20AM -0300, Emiliano Marini wrote:
>> > But be aware that gas is the one GCC uses for in-line assembly embedded
>> in
>> > C programs. So, if you are planning to embed assembly instructions in C
>> > code, you will need to learn gas syntax.
>>
>> I've always wondered how the C code generator manages not to get
>> confused between the registers I use and the ones it allocates.
>>
>> -- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OT: Assembly resources

[Emiliano Marini]

Maybe the C compiler adjusts what registers to use for C code to avoid
conflicts, or saves his registers on the stack before the assembly code.
I'm just guessing, I never embed assembly code in C programs.

On Wed, Mar 2, 2016 at 7:17 PM, Hendrik Boom  wrote:

> On Wed, Mar 02, 2016 at 08:55:20AM -0300, Emiliano Marini wrote:
> > But be aware that gas is the one GCC uses for in-line assembly embedded
> in
> > C programs. So, if you are planning to embed assembly instructions in C
> > code, you will need to learn gas syntax.
>
> I've always wondered how the C code generator manages not to get
> confused between the registers I use and the ones it allocates.
>
> -- hendrik
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Digital camera management borked

[Dr. Nikolaus Klepp]

Am Mittwoch, 2. März 2016 schrieb Rob:
>  Original Message 
> Subject: Re: [DNG] Digital camera management borked
> Local Time: March 2, 2016 9:59 pm
> UTC Time: March 2, 2016 9:59 PM
> From: nuisa...@protonmail.com
> To: dng@lists.dyne.org
> 
> 
> 
>  Original Message 
> Subject: [DNG] Digital camera management borked
> Local Time: March 2, 2016 8:50 pm
> UTC Time: March 2, 2016 8:50 PM
> From: goli...@yahoo.com
> To: dng@lists.dyne.org
> 
> I am having trouble finding a way to browse thumbnails of the photos on my 
> old canon camera. gtkam couldn't access the camera. I installed my old 
> favorite f-spot from wheezy (apparently not available in jessie), but it 
> couldn't even see the camera. The only way I have been able to access the 
> camera is through the thunar file manager at this address (which is in need 
> of some translation):
> 
> gphoto2://[usb:003,036]/DCIM/
> 
> But no image browser can open the jpgs in the folders at that address. Gimp 
> can load only one at a time. It's been frustrating. Thankfully images can be 
> c/p from there.
> 
> My guess is that lack of support is due to the fact that fewer people are 
> using stand-alone cameras. Any suggestions how to get a browse functionality 
> back on Devuan?
> 
> golinux
> 
> 
> Not being funny, have you tried switching the camera off then on again whilst 
> it is connected to your pc. Then Camera/Add camera, auto-detect.
> I have a canon SX40 that requires this procedure occasionally.
> Rob
> 
> *in gtkam*

And maybe the camera has an option in the USB settings for "mass storage".

Nik

-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OT: Assembly resources

[Hendrik Boom]

On Wed, Mar 02, 2016 at 08:55:20AM -0300, Emiliano Marini wrote:
> But be aware that gas is the one GCC uses for in-line assembly embedded in
> C programs. So, if you are planning to embed assembly instructions in C
> code, you will need to learn gas syntax.

I've always wondered how the C code generator manages not to get 
confused between the registers I use and the ones it allocates.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Digital camera management borked

[Rob]

 Original Message 
Subject: Re: [DNG] Digital camera management borked
Local Time: March 2, 2016 9:59 pm
UTC Time: March 2, 2016 9:59 PM
From: nuisa...@protonmail.com
To: dng@lists.dyne.org



 Original Message 
Subject: [DNG] Digital camera management borked
Local Time: March 2, 2016 8:50 pm
UTC Time: March 2, 2016 8:50 PM
From: goli...@yahoo.com
To: dng@lists.dyne.org

I am having trouble finding a way to browse thumbnails of the photos on my old 
canon camera. gtkam couldn't access the camera. I installed my old favorite 
f-spot from wheezy (apparently not available in jessie), but it couldn't even 
see the camera. The only way I have been able to access the camera is through 
the thunar file manager at this address (which is in need of some translation):

gphoto2://[usb:003,036]/DCIM/

But no image browser can open the jpgs in the folders at that address. Gimp can 
load only one at a time. It's been frustrating. Thankfully images can be c/p 
from there.

My guess is that lack of support is due to the fact that fewer people are using 
stand-alone cameras. Any suggestions how to get a browse functionality back on 
Devuan?

golinux


Not being funny, have you tried switching the camera off then on again whilst 
it is connected to your pc. Then Camera/Add camera, auto-detect.
I have a canon SX40 that requires this procedure occasionally.
Rob

*in gtkam*___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Digital camera management borked

[Rob]

 Original Message 
Subject: [DNG] Digital camera management borked
Local Time: March 2, 2016 8:50 pm
UTC Time: March 2, 2016 8:50 PM
From: goli...@yahoo.com
To: dng@lists.dyne.org

I am having trouble finding a way to browse thumbnails of the photos on my old 
canon camera. gtkam couldn't access the camera. I installed my old favorite 
f-spot from wheezy (apparently not available in jessie), but it couldn't even 
see the camera. The only way I have been able to access the camera is through 
the thunar file manager at this address (which is in need of some translation):

gphoto2://[usb:003,036]/DCIM/

But no image browser can open the jpgs in the folders at that address. Gimp can 
load only one at a time. It's been frustrating. Thankfully images can be c/p 
from there.

My guess is that lack of support is due to the fact that fewer people are using 
stand-alone cameras. Any suggestions how to get a browse functionality back on 
Devuan?

golinux


Not being funny, have you tried switching the camera off then on again whilst 
it is connected to your pc. Then Camera/Add camera, auto-detect.
I have a canon SX40 that requires this procedure occasionally.
Rob___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Hendrik Boom]

On Tue, Mar 01, 2016 at 03:05:10PM +, Rainer Weikusat wrote:
> 
> But this already exists. Eg, the machine I usually use for development
> (Debian 6 based) has the following version of libdb installed:
> 
> ii  libdb4.2 4.2.52+dfsg-5 Berkeley v4.2 Database Libraries 
> [runtime]
> ii  libdb4.5 4.5.20-13 Berkeley v4.5 Database Libraries 
> [runtime]
> ii  libdb4.6 4.6.21-16 Berkeley v4.6 Database Libraries 
> [runtime]
> ii  libdb4.7 4.7.25-9  Berkeley v4.7 Database Libraries 
> [runtime]
> ii  libdb4.8 4.8.30-2  Berkeley v4.8 Database Libraries 
> [runtime]
> ii  libdb4.8-dev 4.8.30-2  Berkeley v4.8 Database Libraries 
> [development]
> 
> That's just a matter of using a different soname whenever something
> changes in a backward incompatible way. Even for cases where the soname
> is fixed 'for political reasons' aka 'glibc', the issue is supposed to
> be handled transparently via symbol versioning.

It seems to me that a decade or more ago, I read that this was the standard
Linux way to name multiple versions of libraries.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OT: Assembly resources

[Emiliano Marini]

You welcome.

BTW: about debugging with ddd, you have the (huge) manual here
http://www.gnu.org/software/ddd/manual/pdf/ddd.pdf
Or a nice quick guide here
http://cs.smith.edu/~thiebaut/classes/231_0708/doc/quickstart.html

Greetings,
Emiliano.


On Wed, Mar 2, 2016 at 5:05 PM, Mitt Green  wrote:

> Thanks for the advice and the links, Emiliano.
> I appreciate it.
>
> Peace,
> Mitt
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Dependency Hell: was leveldb support proposal

[Mitt Green]

‎Stephanie Daugherty wrote:‎

>There's a fairly elegant, but seldom used solution
>to this problem,. GNU Stow, which is designed to
>basically be a "package manager" for locally installed
>packages.
‎
What about checkinstall? It can create a .deb package
by checkinstall -D. So, instead of make install, ye use this.

Mitt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Dependency Hell: was leveldb support proposal

[Stephanie Daugherty]

There's a fairly elegant, but seldom used solution to this problem,. GNU
Stow, which is designed to basically be a "package manager" for locally
installed packages.

It works by using symlinks, so that a "package" foo might be installed into
/usr/local/stow/foo and have bin/  and lib/ and all the other expected
subdirectories. Stow will then install that "package" into the  /usr/local
hierarchy proper on command by symlinking each file into the proper place,
and as an intended side effect of this design, Stow, or even a simple
she'll script can easily find all the symlinks to remove later, since they
all point to the actual installed files in the package installation
directory.

On Wed, Mar 2, 2016, 12:05 Edward Bartolo  wrote:

> Hi,
>
> On 02/03/2016, Steve Litt  wrote:
> > I'm not recommending this for every app. But I've got to tell you, when
> > you think about installation by package manager, with its pinnings and
> > exclusions and dependencies and conflicts, not to mention sabotage of
> > packaging by the poetterists and their ilk, installation by directory
> > starts to have its own charm, for certain applications.
> >
> > SteveT
>
> However, does copying a directory tree to install a program go against
> conventions where various parts of an installation should be placed?
>
> Edward
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Digital camera management borked

[Mitt Green]

There's Shotwell, that had been working for me
for quite some time. It's a photo organiser, and
may help.

Mitt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Digital camera management borked

[Ron]

On Wed, 2 Mar 2016 20:50:35 + (UTC)
Go Linux  wrote:

> I am having trouble finding a way to browse thumbnails of the photos on my 
> old canon camera.  gtkam couldn't access the camera.  I installed my old 
> favorite f-spot from wheezy (apparently not available in jessie), but it 
> couldn't even see the camera.  The only way I have been able to access the 
> camera is through the thunar file manager at this address (which is in need 
> of some translation): 

Did you try gThumb ?
 
Cheers,
 
Ron.
-- 
   The plural of "anecdote" is not "data".

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Rainer Weikusat]

"T.J. Duchene"  writes:
> On 2016-03-02 16:20, Rainer Weikusat wrote:
>> The soname mechanism already provides an opportunity for having multiple
>> version of the same library installed as these cane use different
>> sonames but provide the same set of symbols. In addition to this, the
>> symbols themselves can be versioned which enables a single library to
>> provide different versions of a function with the same name, eg
>>
>
> Yes. All true.
>
> Libraries are installed and then linked using sonames that are
> symlinked rather than using the full soname.  This is the proper way,
> so that you don't have to recompile and re-link every single time when
> a minor update is made.  The full length sonames aren't used on a
> day-to-day basis.   It is possible that a short form (symlinked)
> soname  can get re-pointed from the distributions chosen version to
> whatever version was installed last.  It's a human oversight, but it
> can cause problems with the linker.

You seem to be somewhat confused re: How this works and what it's
supposed to accomplish. The soname is a property of a particular library
file, eg, using libdb4 as example,

[rw@duesterwald]/usr/lib $readelf -d libdb-4.8.so | grep -i son
 0x000e (SONAME) Library soname: [libdb-4.8.so]

and that's one the runtime linker cares about: When handling a NEEDED
entry in an ELF binary, it searches for a file with a matching SONAME
entry. The soname will usually be identical to/ reflected in the
filename but it doesn't have to be in this way. The prominent
counterexample would be the C libary whose soname has been fixed as
libc.so.6 regardless of the actual library version:

[rw@doppelsaurus]/lib#readelf -d /lib/x86_64-linux-gnu/libc-2.13.so | grep -i 
son
 0x000e (SONAME) Library soname: [libc.so.6]
(example is for the actual C library file of a Wheezy install)

But that's just one side of the issue, the one concerned with locating a
library when starting an application. The other would be 'locating a
library when compiling/ linking one'. The information the
linker is supplied with will usually just be the proper name of the
library, the first part of the filename minus the leading lib,
eg, in order to link with the Berkeley DB library, one would usually
pass an argument of

-ldb

to the linker (driver). The linker will then search for a file named

lib.so

in its library search path. This will usually be a symlink to most
recent installed version of a library, eg,

[rw@duesterwald]/usr/lib $ls -l libdb.so
lrwxrwxrwx 1 root root 12 Oct  9  2013 libdb.so -> libdb-4.8.so

and the soname in this file will then end up in a NEEDED section.

The idea behind this is that someone compiling an application will want
to associate it with the most recent version of "a certain libray", eg,
the Berkeley DB library, while an already compiled application should
continue to be runtime-linked with the library version it was compiled
with.

> That is what I was referring to when I made my earlier comment about
> the linker becoming "confused."  It's not a correct answer in
> programming terms, but it is a very human one.

You've omitted a few steps on the path to the ultimate disaster: It will
usually also involve trying to "update the system" by copying random
stuff compiled from sources over some set of system-provided files
(especially effective for the C library as this will cause all running
applications to crash once they try to call into it and may prevent
starting new ones :-) and/ or trying to fixup the links manually based
on a half-cocked understanding of their purpose.

But handling this correctly is really not that difficult, even when
doing it manually: Provided a library file named in a suitable way has
been deposited in a library directory, eg, /usr/local/lib, invoking
ldconfig (as root, obviously) will take care of the rest, including
updating the runtime linker cache.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Digital camera management borked

[Go Linux]

I am having trouble finding a way to browse thumbnails of the photos on my old 
canon camera.  gtkam couldn't access the camera.  I installed my old favorite 
f-spot from wheezy (apparently not available in jessie), but it couldn't even 
see the camera.  The only way I have been able to access the camera is through 
the thunar file manager at this address (which is in need of some translation):

gphoto2://[usb:003,036]/DCIM/

But no image browser can open the jpgs in the folders at that address.   Gimp 
can load only one at a time.  It's been frustrating. Thankfully images can be 
c/p from there.

My guess is that lack of support is due to the fact that fewer people are using 
stand-alone cameras.  Any suggestions how to get a browse functionality back on 
Devuan?

golinux




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OT: Assembly resources

[Mitt Green]

Thanks for the advice and the links, Emiliano.
I appreciate it.

Peace,
Mitt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Edward Bartolo]

Hi,

I think, multiple libraries can still reside in an installation of
Debian/Devuan, provided some preparation is done before attempting to
run programs that may require conflicting library version. The only
limitation is the kernel which has to be compatible with all used
libraries.

I would workaround such a problem as follows:
a) copy all executables to the same directory including all .so files
b) use a script to run the executable by using the command:
ld-2.19.so or whatever version is installed on the system

This particular .so file is in a reality an executable that loads and
prepares an executable file linking it with all its required libraries
before running it. The command would specify the executable to be run
and the path to its libraries as follows:

/lib/x86_64-linux-gnu$ ./ld-2.19.so --library-path . /bin/ls

In this example I used ld-2.19.so to run ls.


Edward


On 02/03/2016, T.J. Duchene  wrote:
>
> Perhaps my greatest error was assuming that anyone one the list would
> need or even want a "dumbed down" explanation.  In that case, it is most
> certainly a "mea culpa" on my part.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[T.J. Duchene]

Perhaps my greatest error was assuming that anyone one the list would 
need or even want a "dumbed down" explanation.  In that case, it is most 
certainly a "mea culpa" on my part.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Joel Roth]

Hi Rainer,

Rainer Weikusat wrote:
> As I already wrote twice, program's aren't "linked" to dynamic libraries
> at all. At link time, the sonames of required dynamic libaries are
> recorded in the binary,
> 
> [rw@doppelsaurus]~#readelf -d /bin/bash | grep -i needed
>  0x0001 (NEEDED) Shared library: [libtinfo.so.5]
>  0x0001 (NEEDED) Shared library: [libdl.so.2]
>  0x0001 (NEEDED) Shared library: [libc.so.6]

[more good stuff]

> In case you really care about the technical details, a good description
> is available here:
> 
> https://www.akkadia.org/drepper/dsohowto.pdf

Thanks for this and other contributions! Your clear
explanations and code snippets add a lot to the (high IMO)
level of discussion here. It's a pleasure to learn more 
about how various parts of the Debian/Devuan/Linux OS works.

Cheers,

-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Dependency Hell: was leveldb support proposal

[Edward Bartolo]

Hi,

On 02/03/2016, Steve Litt  wrote:
> I'm not recommending this for every app. But I've got to tell you, when
> you think about installation by package manager, with its pinnings and
> exclusions and dependencies and conflicts, not to mention sabotage of
> packaging by the poetterists and their ilk, installation by directory
> starts to have its own charm, for certain applications.
>
> SteveT

However, does copying a directory tree to install a program go against
conventions where various parts of an installation should be placed?

Edward
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Rainer Weikusat]

Hendrik Boom  writes:
> On Wed, Mar 02, 2016 at 12:45:22PM +1300, Daniel Reurich wrote:

[libdb4 & Bitcoin]

>> The risk is that issues that have been fixed in later libdb versions
>> remain broken in the version that bitcoin statically links in.  So there
>> is a trade off either way, and what is the better approach... fix
>> bitcoin or forever hold onto an obsolete library for one package where
>> the maintainers refuse to switch to a newer version.
>
> It's probably the job of the bitcoin developers to watch deveopments 
> in that other library and decide when it is safe or necessary to change 
> versions.

There's an obvious, alternate option: libdb is (certainly at least until
4.8) BSD-licensed. This means "the right version" can just be
integrated into the Bitcoin code at the expense of the developers having
to maintain it themselves.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] leveldb support proposal

[Rainer Weikusat]

Hendrik Boom  writes:
> On Tue, Mar 01, 2016 at 11:41:46PM +, Rainer Weikusat wrote:
>> "T.J. Duchene"  writes:
>> > On 2016-03-01 20:22, Rainer Weikusat wrote:
>> 
>> And I disgree with your assessment of this being "a simplified"
>> description, instead of a fairly complicated and seriously deceptive
>> one.
>> 
>> >> As single example: Applications aren't "compiled with" dynamic
>> >> libraries, they're combined with them at runtime which happens in the
>> >> same way regardless of the system they were compiled on.
>> >
>> > I am not trying to be rude or condescending, but if you prefer a more
>> > qualified answer to show that I know what I am talking about, then I
>> > must disagree with you.  They are not "combined" with anything except
>> > a set of calls,
>> 
>> Oh, they are. Try running pmap -d $$ in a shell to see this.
>
> As I once understood it, programs are linked to a stub.  When the 
> dynamic shared libraries are loaded, the stub s filled in with the 
> addresses of the real library entry points.

As I already wrote twice, program's aren't "linked" to dynamic libraries
at all. At link time, the sonames of required dynamic libaries are
recorded in the binary,

[rw@doppelsaurus]~#readelf -d /bin/bash | grep -i needed
 0x0001 (NEEDED) Shared library: [libtinfo.so.5]
 0x0001 (NEEDED) Shared library: [libdl.so.2]
 0x0001 (NEEDED) Shared library: [libc.so.6]

and at runtime, the runtime linker locates libraries 'claiming' the
needed sonames by searching through a certain set of directories (it's
actually using a cache but I am trying to simplify things). It maps the
corresponding shared objects into the address space of the process and
use the information in them to connect calls made in the applications
with actual routines available in these libraries based on searching for
'symbols' needed by an application in the set of 'symbols' provided by
the libraries, eg, the bash binary requests of of the following symbols
(that's a subset),

[rw@doppelsaurus]~#nm -D /bin/bash  | grep 'U dl'
 U dlclose
 U dlerror
 U dlopen
 U dlsym
 
by recording them as 'undefined' (U) and the libdl library provides
symbols with these names,

[rw@doppelsaurus]~#nm -D /usr/lib/x86_64-linux-gnu/libdl.so | grep 'T dl'
15e0 T dladdr
1600 T dladdr1
0ff0 T dlclose
13c0 T dlerror
1640 T dlinfo
1850 T dlmopen
0eb0 T dlopen
1030 T dlsym

The soname mechanism already provides an opportunity for having multiple
version of the same library installed as these cane use different
sonames but provide the same set of symbols. In addition to this, the
symbols themselves can be versioned which enables a single library to
provide different versions of a function with the same name, eg

[rw@doppelsaurus]~#objdump -T  /lib/x86_64-linux-gnu/libc.so.6 | grep 
pthread_cond_signal
000eaac0 gDF .text  0026  GLIBC_2.3.2 
pthread_cond_signal
00115890 gDF .text  0026 (GLIBC_2.2.5) 
pthread_cond_signal

In case you really care about the technical details, a good description
is available here:

https://www.akkadia.org/drepper/dsohowto.pdf
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Dependency Hell: was leveldb support proposal

[Steve Litt]

On Tue, 1 Mar 2016 15:15:05 +0100
Didier Kryn  wrote:

>  I hesitated to reply because I know my answer is politically 
> incorrect. "dependency hell" is the consequence of dynamic linkage. I 
> understand that dynamic linkage is a necessity for distros, but if
> the concern is about one package, this very one can be linked
> statically. 

I'm constructing my wpa_supplicant toolset. So far it's 100% /bin/sh.
Installation involves nothing more than copying its directory tree
somewhere on your computer, and then, on your executable path, putting
a 1 line shellscript that calls the main program in my toolset with
argument $@.

I can copy it to any machine with those two operations, and remove it
by deleting the directory tree and the 1 line shellscript.

I'd like to take credit for this easy installation idea, but of course I
can't. This was the main way of installing programs on MS-DOS. No DLLs.
No .so's. No registry. Just copy the directory, and bang, you're
installed. And so it is that, today, I can still run WordPerfect 5.0,
or Clarion 2.1, decades after my Windows programs became unrunnable.

Let me show you my top level shellscript:

=
#!/bin/sh
mydir=`realpath $0 | sed -e's+/[^/]*$++'`
export PATH=$mydir:$PATH
export AP_SELECTION=/tmp/ap_selection.txt
fcn=$mydir/rw_$1.sh
shift
if test -f $fcn -a -x $fcn; then
$fcn $@
else
echo FAIL: File $fcn must exist and be executable. >&2
echo Aborting. >&2
exit 61
fi
=

Installation by directory is as simple as realpath $0.

I'm not recommending this for every app. But I've got to tell you, when
you think about installation by package manager, with its pinnings and
exclusions and dependencies and conflicts, not to mention sabotage of
packaging by the poetterists and their ilk, installation by directory
starts to have its own charm, for certain applications.

SteveT

Steve Litt 
February 2016 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OT: Assembly resources

[Emiliano Marini]

Honestly, I use yasm because it was Teacher's choice before I was a
Teaching Assistant. Anyways, yasm supports gas and nasm syntax, and
multiple binary object formats. yasm/nasm use a syntax similar to Intel's,
and gas uses a syntax similar to AT It's a matter of taste but, to me,
AT it's less readable. Check this page:

http://www.imada.sdu.dk/Courses/DM18/Litteratur/IntelnATT.htm

I think you should pick the one with the syntax more comfortable to you.
But be aware that gas is the one GCC uses for in-line assembly embedded in
C programs. So, if you are planning to embed assembly instructions in C
code, you will need to learn gas syntax.

Check this other page for more info:
https://en.wikibooks.org/wiki/X86_Assembly/x86_Assemblers

Maybe yasm/nasm (Intel's syntax) is more adequate to learn/teach assembly,
and gas to production (again, if you are planning to embed assembly in C
programs, and you are using GCC).

Thanks for sharing those links.

Cheers,
Emiliano.

On Tue, Mar 1, 2016 at 5:10 PM, Mitt Green  wrote:

> Emiliano Marini wrote:
>
>
> >I teach assembly, but x86. I use yasm to compile and ddd to debug.
>
> >You can start with this:
>
>
> [...]
>
>
> Thank you, sir, that's galore. I myself found asm.sourceforge.net
> and dugan from LQ recommended me http://programminggroundup.blogspot.ca/
>
> Why do you use yasm? If we consider the three, gas, nasm and yasm,
> which one is, say, preferred by many and why?
>
>
> Mitt
>
> P.S. Accidentally sent this to dng dash request at lists dot dyne dot org.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng