All of lore.kernel.org
 help / color / mirror / Atom feed
* stripping of ceph class objects
@ 2010-12-16 23:35 Yehuda Sadeh Weinraub
  2010-12-16 23:55 ` Sage Weil
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Yehuda Sadeh Weinraub @ 2010-12-16 23:35 UTC (permalink / raw)
  To: Laszlo Boszormenyi, ceph-devel; +Cc: Sage Weil

Hi Laszlo,

 we just installed the latest ceph debian packages and it seems that
the class objects (that are installed in /usr/lib/rados-classes/) are
stripped. We need to keep a few symbols visible on those shared
objects, namely, all the symbols that start with '__cls_'. Our regular
automake resulted binaries keeps those symbols, but I guess that the
debian packaging strips them.
These symbols have the class name and version in them, which helps us
in cases where the ceph installation is running on a cluster that
consists of multiple architectures. A script running on the monitor
thus should be able to identify the class name and version no matter
what its architecture is.

Thanks,
Yehuda

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: stripping of ceph class objects
  2010-12-16 23:35 stripping of ceph class objects Yehuda Sadeh Weinraub
@ 2010-12-16 23:55 ` Sage Weil
  2010-12-17  6:53 ` Jeff Wu
  2010-12-17 10:49 ` Laszlo Boszormenyi
  2 siblings, 0 replies; 5+ messages in thread
From: Sage Weil @ 2010-12-16 23:55 UTC (permalink / raw)
  To: Yehuda Sadeh Weinraub; +Cc: Laszlo Boszormenyi, ceph-devel

On Thu, 16 Dec 2010, Yehuda Sadeh Weinraub wrote:
>  we just installed the latest ceph debian packages and it seems that
> the class objects (that are installed in /usr/lib/rados-classes/) are
> stripped. We need to keep a few symbols visible on those shared
> objects, namely, all the symbols that start with '__cls_'. Our regular
> automake resulted binaries keeps those symbols, but I guess that the
> debian packaging strips them.

Just to be clear, the package before the recent changes preserved those 
symbols.  I can't remember exactly how, but it was a bit of hack.

sage



> These symbols have the class name and version in them, which helps us
> in cases where the ceph installation is running on a cluster that
> consists of multiple architectures. A script running on the monitor
> thus should be able to identify the class name and version no matter
> what its architecture is.
> 
> Thanks,
> Yehuda
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: stripping of ceph class objects
  2010-12-16 23:35 stripping of ceph class objects Yehuda Sadeh Weinraub
  2010-12-16 23:55 ` Sage Weil
@ 2010-12-17  6:53 ` Jeff Wu
  2010-12-17 10:49 ` Laszlo Boszormenyi
  2 siblings, 0 replies; 5+ messages in thread
From: Jeff Wu @ 2010-12-17  6:53 UTC (permalink / raw)
  To: Laszlo Boszormenyi, Yehuda Sadeh Weinraub; +Cc: ceph-devel, sage



在 2010-12-17五的 07:35 +0800,Yehuda Sadeh Weinraub写道:
> Hi Laszlo,
> 
>  we just installed the latest ceph debian packages and it seems that
> the class objects (that are installed in /usr/lib/rados-classes/) are
> stripped. We need to keep a few symbols visible on those shared
> objects, namely, all the symbols that start with '__cls_'. Our regular
> automake resulted binaries keeps those symbols, but I guess that the
> debian packaging strips them.

Hi ,
If only stripped debugging symbols and sections,
Could which keep these symbols ?

Like this:
------------
strip --strip--debug rados-classes/libcls_rbd.so.1.0.0
strip --strip--debug libceph.so.1.0.0 
strip --strip--debug libcrush.so.1.0.0  
strip --strip--debug librados.so.1.0.0  


> These symbols have the class name and version in them, which helps us
> in cases where the ceph installation is running on a cluster that
> consists of multiple architectures. A script running on the monitor
> thus should be able to identify the class name and version no matter
> what its architecture is.
> 
> Thanks,
> Yehuda
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: stripping of ceph class objects
  2010-12-16 23:35 stripping of ceph class objects Yehuda Sadeh Weinraub
  2010-12-16 23:55 ` Sage Weil
  2010-12-17  6:53 ` Jeff Wu
@ 2010-12-17 10:49 ` Laszlo Boszormenyi
  2010-12-17 16:49   ` Sage Weil
  2 siblings, 1 reply; 5+ messages in thread
From: Laszlo Boszormenyi @ 2010-12-17 10:49 UTC (permalink / raw)
  To: Yehuda Sadeh Weinraub; +Cc: ceph-devel, Sage Weil

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

Hi Yehuda,

On Thu, 2010-12-16 at 15:35 -0800, Yehuda Sadeh Weinraub wrote:
>  we just installed the latest ceph debian packages and it seems that
> the class objects (that are installed in /usr/lib/rados-classes/) are
> stripped. [...] Our regular
> automake resulted binaries keeps those symbols, but I guess that the
> debian packaging strips them.
 Indeed, the packaging stripped them. The attached patch fixes this
issue. Also ceph.lintian should be ceph.lintian-overrides .
I'm a bit confused, why ceph should depend explicitly on binutils? I may
understand libedit2 as ceph build depends on its -dev counterpart; but I
couldn't find a binary that is linked with it.

Sage, is it OK if I commit this patch?

Cheers,
Laszlo/GCS

[-- Attachment #2: ceph-packaging.diff --]
[-- Type: text/x-patch, Size: 1609 bytes --]

diff --git a/debian/ceph.lintian-overrides b/debian/ceph.lintian-overrides
index 6463e89..566fc33 100644
--- a/debian/ceph.lintian-overrides
+++ b/debian/ceph.lintian-overrides
@@ -1,4 +1,5 @@
 #
 # the rados classes should NOT be stripped.
 #
-ceph binary: unstripped-binary-or-object ./usr/lib/rados-classes/libcls_rbd.so.1.0.0
+ceph: unstripped-binary-or-object ./usr/lib/rados-classes/libcls_rbd.so.1.0.0
+
diff --git a/debian/control b/debian/control
index bc1247f..d3dc2bf 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Standards-Version: 3.9.1
 
 Package: ceph
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, libedit2, hdparm, binutils
+Depends: ${shlibs:Depends}, ${misc:Depends}, hdparm
 Recommends: ceph-client-tools, ceph-fuse, libceph1, librados1, libcrush1, btrfs-tools
 Description: distributed storage and file system
  Ceph is a distributed storage and network file system designed to provide
diff --git a/debian/rules b/debian/rules
index 5b99834..1941750 100755
--- a/debian/rules
+++ b/debian/rules
@@ -61,14 +61,13 @@ binary-arch: build install
 	dh_lintian
 	dh_link
 
-	dh_strip -pceph --dbg-package=ceph-dbg
+	dh_strip -pceph --dbg-package=ceph-dbg -k --exclude=libcls_
 	dh_strip -pceph-fuse --dbg-package=ceph-fuse-dbg
 	dh_strip -pceph-client-tools --dbg-package=ceph-client-tools-dbg
 	dh_strip -plibcrush1 --dbg-package=libcrush1-dbg
 	dh_strip -plibrados1 --dbg-package=librados1-dbg
 	dh_strip -plibceph1 --dbg-package=libceph1-dbg
 	dh_strip -pradosgw --dbg-package=radosgw-dbg
-#	dh_strip -k --exclude=libcls_
 
 	dh_compress
 	dh_fixperms

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: stripping of ceph class objects
  2010-12-17 10:49 ` Laszlo Boszormenyi
@ 2010-12-17 16:49   ` Sage Weil
  0 siblings, 0 replies; 5+ messages in thread
From: Sage Weil @ 2010-12-17 16:49 UTC (permalink / raw)
  To: Laszlo Boszormenyi; +Cc: Yehuda Sadeh Weinraub, ceph-devel

On Fri, 17 Dec 2010, Laszlo Boszormenyi wrote:
> Hi Yehuda,
> 
> On Thu, 2010-12-16 at 15:35 -0800, Yehuda Sadeh Weinraub wrote:
> >  we just installed the latest ceph debian packages and it seems that
> > the class objects (that are installed in /usr/lib/rados-classes/) are
> > stripped. [...] Our regular
> > automake resulted binaries keeps those symbols, but I guess that the
> > debian packaging strips them.
>  Indeed, the packaging stripped them. The attached patch fixes this
> issue. Also ceph.lintian should be ceph.lintian-overrides .

Thanks.

> I'm a bit confused, why ceph should depend explicitly on binutils? I may
> understand libedit2 as ceph build depends on its -dev counterpart; but I
> couldn't find a binary that is linked with it.

cclsinfo uses 'nm', which is in binutils.  And ceph is linked against 
-ledit.

I committed the rest.  Thanks!
sage


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2010-12-17 16:44 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-16 23:35 stripping of ceph class objects Yehuda Sadeh Weinraub
2010-12-16 23:55 ` Sage Weil
2010-12-17  6:53 ` Jeff Wu
2010-12-17 10:49 ` Laszlo Boszormenyi
2010-12-17 16:49   ` Sage Weil

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.