Ok good! We must support the case where OpenSAF is linked with one C++ standard library and an application which is using OpenSAF (and linking with the OpenSAF agent libraries) is linked with another C++ standard library (either libc++ or another version of libstdc++). If we feel confident that it works then I don't see any problem with C++ in the agent libraries.
regards, Anders Widell On 02/12/2016 02:03 PM, Hans Nordebäck wrote: > 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
