Question about libconnectivity_abstraction and its supposed internal
variant connectivity_abstraction_internal. It looks to me like
_internal is really a thing which matters on Windows only. One place
tries to explain this:
=== resource/csdk/stack/SConscript: ===
if target_os not in ['windows', 'msys_nt']:
liboctbstack_env.PrependUnique(LIBS=['connectivity_abstraction'])
else:
# On Windows, apps don't link directly with
connectivity_abstraction.
# connectivity_abstraction is linked inside octbstack.dll and apps
# import its APIs by linking with octbstack.lib.
liboctbstack_env.PrependUnique(LIBS=['connectivity_abstraction_internal'])
===
But elsewhere, one or the other is just used pretty much
unconditionally. On Linux at least, this creates some problems. One
existing location has tried to work around a found problem:
=== resource/csdk/connectivity/test/SConscript: ===
if target_os not in ['msys_nt', 'windows']:
# ssladapter_test.cpp #includes ca_adapter_net_ssl.c! That results in
# "multiple definition" linker errors, when trying to link with
# connectivity_abstraction_internal here.
catest_env.PrependUnique(LIBS=['connectivity_abstraction'])
else:
catest_env.PrependUnique(LIBS=['connectivity_abstraction_internal'])
===
And I've this week battled a problem which cropped up after some merges.
went in from 1.3-rel to master. In
resource/provisioning/unittests/SConscript,
connectivity_abstraction_internal is linked in preference to the public
one, however now because some other libraries linked into the
provisioning unittest require libconnectivity_abstraction and it does
not appear on the link line, there are link failures. This error may be
caused by a newer linker on my system because I'm not seeing this
problem in, say, Jenkins-initiated builds.
So, what is the difference between the two?
Not much, it seems.
-rw-rw-r--. 1 mats mats 2681848 Sep 18 11:05 libconnectivity_abstraction.a
-rw-rw-r--. 1 mats mats 2681848 Sep 18 11:05
libconnectivity_abstraction_internal.a
-rwxrwxr-x. 1 mats mats 2734960 Sep 18 11:05 libconnectivity_abstraction.so
Trimmed pieces from the construction:
=== resource/csdk/connectivity/src/SConscript ===
calib_internal = connectivity_env.StaticLibrary(
'connectivity_abstraction_internal', connectivity_env.get('CA_SRC'))
calib = Flatten(calib_internal)
if ca_os in ['android', 'tizen', 'linux', 'yocto']:
static_calib = connectivity_env.StaticLibrary(
'connectivity_abstraction', connectivity_env.get('CA_SRC'))
shared_calib = connectivity_env.SharedLibrary(
'connectivity_abstraction', connectivity_env.get('CA_SRC'))
calib += Flatten([static_calib, shared_calib])
elif ca_os not in ['msys_nt', 'windows']:
static_calib = connectivity_env.StaticLibrary(
'connectivity_abstraction', connectivity_env.get('CA_SRC'))
calib += Flatten(static_calib)
connectivity_env.InstallTarget(calib, 'connectivity_abstraction')
connectivity_env.UserInstallTargetLib(calib, 'connectivity_abstraction')
===
The three variants: the internal StaticLibrary and the public
StaticLibrary and SharedLibrary are built from exactly the same sources,
namely the contents of CA_SRC which has previously been assembled here
and in other build scripts. Which are built depends on platform, but
the build itself does not differ. The linux-y flavors get the shared
library, the others don't; windows doesn't get the public one at all.
The two static archives are identical after a Linux build.
The problem needing the workaround above is because two libraries with
the same content get linked, one shared and one static - I'm surprised
this problem doesn't come up in other places. The change applied there,
to use libca instead of libca_int, means the linker can sort it out - it
doesn't care if there are two of the /same/ library being linked.
So what is the purpose? Should the scripts be updated so the _internal
version is indeed Windows-only and not constructed/requested for the
other platforms? Was there some original intent either lost, or not yet
implemented, other than the Windows issue from the comment above, for
having both?
Since they're currently the same, why would any app that is able to
successfully link with the "public" one want to link with the "internal"
one instead?
_______________________________________________
iotivity-dev mailing list
iotivity-dev@lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
