Re: Recompiling source code - to find exact RPM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey Brad,

Many thanks for the explanation...

> ~~~
> WARNING: the following dangerous and experimental features are enabled:
> ~~~

> Can I ask why you want to disable this warning?

We using bluestore with kraken, we are aware that this is in tech preview. To hide these warning compiled like this.

Thanks 


On Mon, Mar 27, 2017 at 5:04 AM, Brad Hubbard <bhubbard@xxxxxxxxxx> wrote:


On Fri, Mar 24, 2017 at 6:49 PM, nokia ceph <nokiacephusers@xxxxxxxxx> wrote:
> Brad, cool now we are on the same track :)
>
> So whatever change we made after this location src/* as it mapped to
> respective rpm correct?
>
> For eg:-
> src/osd/* -- ceph-osd
> src/common - ceph-common
> src/mon  - ceph-mon
> src/mgr   - ceph-mgr

I think this is true in most, if not all, cases.

>
> Since we are using bluestore with kraken, I though to disable the below
> warning while triggering `ceph -s`
>
> ~~~
> WARNING: the following dangerous and experimental features are enabled:
> ~~~

Can I ask why you want to disable this warning?

>
> Here I made a comment in this file
>
>>vim src/common/ceph_context.cc
> 307 //      if (!cct->_experimental_features.empty())
> 308 //      lderr(cct) << "WARNING: the following dangerous and experimental
> features are enabled: "
> 309 //                 << cct->_experimental_features << dendl;

Right.

>
> As per my assumption, the change should reflect in this binary
> "ceph-common"

libceph-common specifically.

>
> But when I closely looked on librados library as these warning showing here
> also.
> #strings -a /usr/lib64/librados.so.2 | grep dangerous
> WARNING: the following dangerous and experimental features are enabled: -->
>
> Then I conclude for this change ceph-common and librados were required.
>
> Please correct me if I'm wrong.

So I looked at this on current master built on Fedora and see the following.

$ for lib in $(find . \! -type l -type f -name lib\*); do strings $lib|grep "following dangerous and experimenta l"; if [ $? -eq 0 ]; then echo $lib; fi; done
WARNING: the following dangerous and experimental features are enabled:
./libcephd.a
WARNING: the following dangerous and experimental features are enabled:
./libceph-common.so.0
WARNING: the following dangerous and experimental features are enabled:
./libcommon.a

So in my case the only shared object that has this string is libceph-common.
However, that library is dynamically linked to libceph-common.

$ ldd librados.so.2.0.0|grep libceph-common
        libceph-common.so.0 => /home/brad/working/src/ceph/build/lib/libceph-common.so.0 (0x00007faa2cf42000)

I checked a rhel version and sure enough the string is there, because in that
version on rhel/CentOS we statically linked libcommon.a into librados IIRC.

# ldd librados.so.2.0.0|grep libceph-common
#

So if the string shows up in your librados then I'd suggest it is also
statically linked ([1] we only changed this fairly recently) and you will need
to replace it to reflect your change.

[1] https://github.com/ceph/ceph/commit/8f7643792c9e6a3d1ba4a06ca7d09b0de9af1443

>
> On Fri, Mar 24, 2017 at 5:41 AM, Brad Hubbard <bhubbard@xxxxxxxxxx> wrote:
>>
>> Oh wow, I completely misunderstood your question.
>>
>> Yes, src/osd/PG.cc and src/osd/PG.h are compiled into the ceph-osd binary
>> which
>> is included in the ceph-osd rpm as you said in your OP.
>>
>> On Fri, Mar 24, 2017 at 3:10 AM, nokia ceph <nokiacephusers@xxxxxxxxx>
>> wrote:
>> > Hello Piotr,
>> >
>> > I didn't understand, could you please elaborate about this procedure as
>> > mentioned in the last update.  It would be really helpful if you share
>> > any
>> > useful link/doc to understand what you actually meant. Yea correct,
>> > normally
>> > we do this procedure but it takes more time. But here my intention is to
>> > how
>> > to find out the rpm which caused the change. I think we are in opposite
>> > direction.
>> >
>> >>> But wouldn't be faster and/or more convenient if you would just
>> >>> recompile
>> >>> binaries in-place (or use network symlinks)
>> >
>> > Thanks
>> >
>> >
>> >
>> > On Thu, Mar 23, 2017 at 6:47 PM, Piotr Dałek <piotr.dalek@xxxxxxxxxxxx>
>> > wrote:
>> >>
>> >> On 03/23/2017 02:02 PM, nokia ceph wrote:
>> >>
>> >>> Hello Piotr,
>> >>>
>> >>> We do customizing ceph code for our testing purpose. It's a part of
>> >>> our
>> >>> R&D :)
>> >>>
>> >>> Recompiling source code will create 38 rpm's out of these I need to
>> >>> find
>> >>> which one is the correct rpm which I made change in the source code.
>> >>> That's
>> >>> what I'm try to figure out.
>> >>
>> >>
>> >> Yes, I understand that. But wouldn't be faster and/or more convenient
>> >> if
>> >> you would just recompile binaries in-place (or use network symlinks)
>> >> instead
>> >> of packaging entire Ceph and (re)installing its packages each time you
>> >> do
>> >> the change? Generating RPMs takes a while.
>> >>
>> >>
>> >> --
>> >> Piotr Dałek
>> >> piotr.dalek@xxxxxxxxxxxx
>> >> https://www.ovh.com/us/
>> >
>> >
>> >
>> > _______________________________________________
>> > ceph-users mailing list
>> > ceph-users@xxxxxxxxxxxxxx
>> > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
>> >
>>
>>
>>
>> --
>> Cheers,
>> Brad
>
>



--
Cheers,
Brad

_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux