it should also be possible to have different stdc++ libraries, for
example an c++ application is compiled with clang++ and linked with
libc++ (clang std lib) and also linked with libfoo2 that is linked
towards stdc++.
c++ application:
clang++ -std=c++11 -stdlib=libc++ -o call_foo call_foo.cc -L. -lfoo2
library (could be e.g the amf api library):
g++ -Wall -fPIC -c foo2.cc -I.
g++ -Wall -shared -Wl,-soname,libfoo2.so.1 -o libfoo2.so foo2.o Foo.o
ldd call_foo
linux-vdso.so.1 => (0x00007ffcd90b3000)
libfoo2.so.1 => ./libfoo2.so.1 (0x00007f8647a06000)
libc++.so.1 => /usr/lib/x86_64-linux-gnu/libc++.so.1
(0x00007f8647714000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f864740e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007f86471f8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8646e33000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007f8646b2f000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f8646911000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f8646709000)
ldd libfoo2.so
linux-vdso.so.1 => (0x00007fffa8b61000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007f1a0b009000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1a0ac44000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1a0a93e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1a0b510000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007f1a0a728000)
/Hans
On 02/11/2016 10:16 AM, Hans Nordebäck wrote:
> the agent library is a shared library and it adds dependency towards
> stdc++, (if any standard library functions are used). We already have
> a dependency
> towards libc and if there should be any problems as you describe
> below, the agent shared library could be re-built towards the required
> stdc++.
>
> /Thanks Hans
>
> On 02/10/2016 01:41 PM, Anders Widell wrote:
>> Does this add a dependency towards libstdc++ from the agent library?
>> If it does, I think it would be problematic. It could interfere with
>> an application which is also written in C++ but linked against a
>> difference C++ standard library (either a different version of
>> libstdc++, or a completely different implementation like e.g. libc++).
>>
>> / Anders Widell
>>
>> On 02/08/2016 04:37 PM, Hans Nordebäck wrote:
>>> Hi Praveen, Nagu, Mathi and Anders,
>>>
>>> Any comments on this patch? As Gary mentions below, it would e.g.
>>> make supporting long DN a lot easier. /Thanks HansN
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Gary Lee [mailto:[email protected]]
>>> Sent: den 1 februari 2016 09:49
>>> To: Hans Nordebäck
>>> Cc: [email protected]; [email protected]; Anders
>>> Widell; Minh Chau H; [email protected];
>>> [email protected]
>>> Subject: Re: [PATCH 0 of 1] Review Request for amfa: Divide amf api
>>> functions in a thin C layer and use C++ for implementation [#1673]
>>>
>>> Hi Hans
>>>
>>> I think it would be very, very nice if we got rid of SaNameT in
>>> libs/common/osaf, and replaced it with std::string.
>>>
>>> As you know, the data structures defined here are used by the agent,
>>> director and node director.
>>>
>>> There is a lot of code that copies and frees various messages (both
>>> in the common lib and director). It would make supporting long DN a
>>> lot easier, if we didn’t have to worry about SaNameT, and ‘deep
>>> copying’.
>>>
>>> Thanks
>>> Gary
>>>
>>>> On 30 Jan 2016, at 12:39 AM, Hans Nordeback
>>>> <[email protected]> wrote:
>>>>
>>>> Summary: amfa: Divide amf api functions in a thin C layer and use C++
>>>> for implementation Review request for Trac Ticket(s): #1673 Peer
>>>> Reviewer(s): Mathi, AndersW, Praveen, Nagu, Gary, Minh Pull request
>>>> to:
>>>> Affected branch(es): default
>>>> Development branch: default
>>>>
>>>> --------------------------------
>>>> Impacted area Impact y/n
>>>> --------------------------------
>>>> Docs n
>>>> Build system n
>>>> RPM/packaging n
>>>> Configuration files n
>>>> Startup scripts n
>>>> SAF services n
>>>> OpenSAF services n
>>>> Core libraries y
>>>> Samples n
>>>> Tests n
>>>> Other n
>>>>
>>>>
>>>> Comments (indicate scope for each "y" above):
>>>> ---------------------------------------------
>>>> <<EXPLAIN/COMMENT THE PATCH SERIES HERE>>
>>>>
>>>> changeset 20dec14de18f2f5d4095c6d2ef703893e26723d7
>>>> Author: Hans Nordeback <[email protected]>
>>>> Date: Fri, 29 Jan 2016 14:35:14 +0100
>>>>
>>>> amfa: Divide amf api functions in a thin C layer and use C++ for
>>>> implementation [#1673]
>>>>
>>>> The amf agent part is implemented in C and shares C data
>>>> structures with
>>>> amfd and amfnd, e.g. libs/common/osaf. It would be benficial if
>>>> the amf
>>>> agent could be split into two parts, one thin C layer that
>>>> passes the call
>>>> to C++ for the implementation. Then it will be significally
>>>> easier to
>>>> convert libs/common/osaf structures and functions to C++ and
>>>> remove e.g. the
>>>> use of SaNameT and support long DN. The C++ usage at the agent
>>>> could be
>>>> limited to follow C++98 standard to ease acceptance for
>>>> applications. A
>>>> patch is sent out with this change and comments are appreciated.
>>>>
>>>>
>>>> Added Files:
>>>> ------------
>>>> osaf/libs/agents/saf/amfa/include/amf_agent.h
>>>>
>>>>
>>>> Complete diffstat:
>>>> ------------------
>>>> osaf/libs/agents/saf/amfa/Makefile.am | 2 +-
>>>> osaf/libs/agents/saf/amfa/ava_api.c | 4207
>>>> ++++++++++++++++---------------
>>>> osaf/libs/agents/saf/amfa/ava_init.c | 2 +-
>>>> osaf/libs/agents/saf/amfa/include/amf_agent.h | 96 +
>>>> osaf/libs/agents/saf/amfa/include/ava.h | 7 +
>>>> osaf/libs/agents/saf/amfa/include/ava_cb.h | 7 +
>>>> osaf/libs/agents/saf/amfa/include/ava_dl_api.h | 7 +
>>>> osaf/libs/agents/saf/amfa/include/ava_hdl.h | 7 +
>>>> osaf/libs/agents/saf/amfa/include/ava_mds.h | 7 +
>>>> 9 files changed, 2304 insertions(+), 2038 deletions(-)
>>>>
>>>>
>>>> Testing Commands:
>>>> -----------------
>>>> <<LIST THE COMMAND LINE TOOLS/STEPS TO TEST YOUR CHANGES>>
>>>>
>>>>
>>>> Testing, Expected Results:
>>>> --------------------------
>>>> <<PASTE COMMAND OUTPUTS / TEST RESULTS>>
>>>>
>>>>
>>>> Conditions of Submission:
>>>> -------------------------
>>>> <<HOW MANY DAYS BEFORE PUSHING, CONSENSUS ETC>>
>>>>
>>>>
>>>> Arch Built Started Linux distro
>>>> -------------------------------------------
>>>> mips n n
>>>> mips64 n n
>>>> x86 n n
>>>> x86_64 y y
>>>> powerpc n n
>>>> powerpc64 n n
>>>>
>>>>
>>>> Reviewer Checklist:
>>>> -------------------
>>>> [Submitters: make sure that your review doesn't trigger any
>>>> checkmarks!]
>>>>
>>>>
>>>> Your checkin has not passed review because (see checked entries):
>>>>
>>>> ___ Your RR template is generally incomplete; it has too many blank
>>>> entries
>>>> that need proper data filled in.
>>>>
>>>> ___ You have failed to nominate the proper persons for review and
>>>> push.
>>>>
>>>> ___ Your patches do not have proper short+long header
>>>>
>>>> ___ You have grammar/spelling in your header that is unacceptable.
>>>>
>>>> ___ You have exceeded a sensible line length in your
>>>> headers/comments/text.
>>>>
>>>> ___ You have failed to put in a proper Trac Ticket # into your
>>>> commits.
>>>>
>>>> ___ You have incorrectly put/left internal data in your comments/files
>>>> (i.e. internal bug tracking tool IDs, product names etc)
>>>>
>>>> ___ You have not given any evidence of testing beyond basic build
>>>> tests.
>>>> Demonstrate some level of runtime or other sanity testing.
>>>>
>>>> ___ You have ^M present in some of your files. These have to be
>>>> removed.
>>>>
>>>> ___ You have needlessly changed whitespace or added whitespace crimes
>>>> like trailing spaces, or spaces before tabs.
>>>>
>>>> ___ You have mixed real technical changes with whitespace and other
>>>> cosmetic code cleanup changes. These have to be separate commits.
>>>>
>>>> ___ You need to refactor your submission into logical chunks; there is
>>>> too much content into a single commit.
>>>>
>>>> ___ You have extraneous garbage in your review (merge commits etc)
>>>>
>>>> ___ You have giant attachments which should never have been sent;
>>>> Instead you should place your content in a public tree to be
>>>> pulled.
>>>>
>>>> ___ You have too many commits attached to an e-mail; resend as
>>>> threaded
>>>> commits, or place in a public tree for a pull.
>>>>
>>>> ___ You have resent this content multiple times without a clear
>>>> indication
>>>> of what has changed between each re-send.
>>>>
>>>> ___ You have failed to adequately and individually address all of the
>>>> comments and change requests that were proposed in the initial
>>>> review.
>>>>
>>>> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>>>>
>>>> ___ Your computer have a badly configured date and time; confusing the
>>>> the threaded patch review.
>>>>
>>>> ___ Your changes affect IPC mechanism, and you don't present any
>>>> results
>>>> for in-service upgradability test.
>>>>
>>>> ___ Your changes affect user manual and documentation, your patch
>>>> series
>>>> do not contain the patch that updates the Doxygen manual.
>>>>
>>
>>
>
>
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Opensaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
