[jira] [Commented] (DISPATCH-1384) Fix tests in Travis CI on macOS
[
https://issues.apache.org/jira/browse/DISPATCH-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17056676#comment-17056676
]
Jiri Daněk commented on DISPATCH-1384:
--
Still no volunteers as of yet. I'll try to finish it myself today or tomorrow.
The documentation writing part of the contest task would still be available,
even of I manage to fix the tests in this issue
> Fix tests in Travis CI on macOS
> ---
>
> Key: DISPATCH-1384
> URL: https://issues.apache.org/jira/browse/DISPATCH-1384
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Reporter: Jiri Daněk
>Assignee: Jiri Daněk
>Priority: Major
> Labels: macOS
>
> {noformat}
> The following tests FAILED:
> 9 - unit_tests (SEGFAULT)
>23 - system_tests_policy (Timeout)
>28 - system_tests_sasl_plain (Failed)
>38 - system_tests_auth_service_plugin (Failed)
>39 - system_tests_authz_service_plugin (Failed)
>48 - system_tests_bad_configuration (Failed)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1579) Traffic hangs when multiple large messages are sent using different priorities
[ https://issues.apache.org/jira/browse/DISPATCH-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17056146#comment-17056146 ] ASF subversion and git services commented on DISPATCH-1579: --- Commit 0264301cf9a1fb6e767f75d4e1aeabecf7355e2a in qpid-dispatch's branch refs/heads/master from Ken Giusti [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=0264301 ] DISPATCH-1579: open dedicated inter-router sessions for data and control links > Traffic hangs when multiple large messages are sent using different priorities > -- > > Key: DISPATCH-1579 > URL: https://issues.apache.org/jira/browse/DISPATCH-1579 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.10.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Blocker > Fix For: 1.11.0 > > > Create a two hop router network. Attach a single receiver on one router. > Create 10 senders on the other router. Each sender should sent a large > number of (unsettled) messages at a given priority (IOW 10 senders, one > sender sends priority 0 messages, another sends priority 1 messages, etc). > If the messages are large enough to trigger Q3 eventually most (all?) of the > senders will hang stuck waiting for either settlement or deliveries to be > forwarded. There is no recovery. > I will post a reproducer soon. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1579) Traffic hangs when multiple large messages are sent using different priorities
[ https://issues.apache.org/jira/browse/DISPATCH-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-1579. -- Resolution: Fixed > Traffic hangs when multiple large messages are sent using different priorities > -- > > Key: DISPATCH-1579 > URL: https://issues.apache.org/jira/browse/DISPATCH-1579 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.10.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Blocker > Fix For: 1.11.0 > > > Create a two hop router network. Attach a single receiver on one router. > Create 10 senders on the other router. Each sender should sent a large > number of (unsettled) messages at a given priority (IOW 10 senders, one > sender sends priority 0 messages, another sends priority 1 messages, etc). > If the messages are large enough to trigger Q3 eventually most (all?) of the > senders will hang stuck waiting for either settlement or deliveries to be > forwarded. There is no recovery. > I will post a reproducer soon. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1579) Traffic hangs when multiple large messages are sent using different priorities
[ https://issues.apache.org/jira/browse/DISPATCH-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17056148#comment-17056148 ] ASF GitHub Bot commented on DISPATCH-1579: -- asfgit commented on pull request #693: DISPATCH-1579: open dedicated inter-router sessions for data and control links URL: https://github.com/apache/qpid-dispatch/pull/693 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Traffic hangs when multiple large messages are sent using different priorities > -- > > Key: DISPATCH-1579 > URL: https://issues.apache.org/jira/browse/DISPATCH-1579 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.10.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Blocker > Fix For: 1.11.0 > > > Create a two hop router network. Attach a single receiver on one router. > Create 10 senders on the other router. Each sender should sent a large > number of (unsettled) messages at a given priority (IOW 10 senders, one > sender sends priority 0 messages, another sends priority 1 messages, etc). > If the messages are large enough to trigger Q3 eventually most (all?) of the > senders will hang stuck waiting for either settlement or deliveries to be > forwarded. There is no recovery. > I will post a reproducer soon. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1579) Traffic hangs when multiple large messages are sent using different priorities
[ https://issues.apache.org/jira/browse/DISPATCH-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17056147#comment-17056147 ] ASF subversion and git services commented on DISPATCH-1579: --- Commit 074efc57c678d8e06a8fefb0a3d6a2f88c0102c6 in qpid-dispatch's branch refs/heads/master from Ken Giusti [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=074efc5 ] DISPATCH-1579: add logic to activate all links on session Q3 clear This closes #693 > Traffic hangs when multiple large messages are sent using different priorities > -- > > Key: DISPATCH-1579 > URL: https://issues.apache.org/jira/browse/DISPATCH-1579 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.10.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Blocker > Fix For: 1.11.0 > > > Create a two hop router network. Attach a single receiver on one router. > Create 10 senders on the other router. Each sender should sent a large > number of (unsettled) messages at a given priority (IOW 10 senders, one > sender sends priority 0 messages, another sends priority 1 messages, etc). > If the messages are large enough to trigger Q3 eventually most (all?) of the > senders will hang stuck waiting for either settlement or deliveries to be > forwarded. There is no recovery. > I will post a reproducer soon. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] asfgit closed pull request #693: DISPATCH-1579: open dedicated inter-router sessions for data and control links
asfgit closed pull request #693: DISPATCH-1579: open dedicated inter-router sessions for data and control links URL: https://github.com/apache/qpid-dispatch/pull/693 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8425) [qpid-cpp] Channel leak on federation links
[
https://issues.apache.org/jira/browse/QPID-8425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet reassigned QPID-8425:
--
Assignee: Kim van der Riet
> [qpid-cpp] Channel leak on federation links
> ---
>
> Key: QPID-8425
> URL: https://issues.apache.org/jira/browse/QPID-8425
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
> Attachments: BZ1748054.patch, channel_test.sh
>
>
> If a broker is repeatedly killed and restarted when it is federated to
> another broker, the second broker will run out of channels with a "channel
> pool is empty" message. The channel being used for the federation link is not
> being returned to the channel pool, and eventually (after ~32k restarts), the
> channel pool becomes exhausted.
> A reproducer is contained in the attached file "channel_test.sh". If a small
> change is made to the Link.cpp constructor which shrinks the channel pool to
> 5 (see the diff below), then this test will show the error without having to
> wait hours for ~32k restarts. The test does 10 restarts.
> {noformat}
> diff --git a/src/qpid/broker/Link.cpp b/src/qpid/broker/Link.cpp
> index 14737e730..790c8ac5e 100644
> --- a/src/qpid/broker/Link.cpp
> +++ b/src/qpid/broker/Link.cpp
> @@ -149,7 +149,7 @@ Link::Link(const string& _name,
> currentInterval(1),
> reconnectNext(0), // Index of next address for reconnecting in url.
> nextFreeChannel(1),
> - freeChannels(1, framing::CHANNEL_MAX),
> + freeChannels(1, 6),
> connection(0),
> agent(0),
> listener(l),
> {noformat}
> Running the test with the above temporary patch, the following is observed:
> {noformat}
> Channel allocations from broker 6001:
> 3377:2020-03-06 13:29:36 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 1
> 3538:2020-03-06 13:29:36 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 2
> 3739:2020-03-06 13:29:39 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 3
> 3934:2020-03-06 13:29:43 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 4
> 4022:2020-03-06 13:29:47 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 5
> 4110:2020-03-06 13:29:51 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4111:2020-03-06 13:29:51 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> 4154:2020-03-06 13:29:52 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4155:2020-03-06 13:29:52 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> 4253:2020-03-06 13:29:55 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4254:2020-03-06 13:29:55 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> 4297:2020-03-06 13:29:56 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4298:2020-03-06 13:29:56 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> ...
> (repeated several times more)
> {noformat}
>
> A fix which returns the channels on links that are closing to the channel
> pool is suggested in attached patch BZ1748054.patch. With this patch applied
> (together with the temporary pool-shrink patch above), the following is now
> observed:
> {noformat}
> Channel allocations from broker 6001:
> 2020-03-06 12:20:59 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 1
> 2020-03-06 12:20:59 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 2
> 2020-03-06 12:21:02 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 3
> 2020-03-06 12:21:06 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 4
> 2020-03-06 12:21:10 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 5
> 2020-03-06 12:21:14 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 1
> 2020-03-06 12:21:18 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 3
> 2020-03-06 12:21:22 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 4
> 2020-03-06 12:21:26 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 5
> 2020-03-06 12:21:30 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 1
> 2020-03-06 12:21:34 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 3
> 2020-03-06 12:21:38 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 4
> {noformat}
> Channel 2 is used by a bridge which remains open
> (qpid.bridge_session_amq.fanout). The channels are re-used in a cyclical
> pattern, which I think is the intention.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (QPID-8425) [qpid-cpp] Channel leak on federation links
Kim van der Riet created QPID-8425:
--
Summary: [qpid-cpp] Channel leak on federation links
Key: QPID-8425
URL: https://issues.apache.org/jira/browse/QPID-8425
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Reporter: Kim van der Riet
Attachments: BZ1748054.patch, channel_test.sh
If a broker is repeatedly killed and restarted when it is federated to another
broker, the second broker will run out of channels with a "channel pool is
empty" message. The channel being used for the federation link is not being
returned to the channel pool, and eventually (after ~32k restarts), the channel
pool becomes exhausted.
A reproducer is contained in the attached file "channel_test.sh". If a small
change is made to the Link.cpp constructor which shrinks the channel pool to 5
(see the diff below), then this test will show the error without having to wait
hours for ~32k restarts. The test does 10 restarts.
{noformat}
diff --git a/src/qpid/broker/Link.cpp b/src/qpid/broker/Link.cpp
index 14737e730..790c8ac5e 100644
--- a/src/qpid/broker/Link.cpp
+++ b/src/qpid/broker/Link.cpp
@@ -149,7 +149,7 @@ Link::Link(const string& _name,
currentInterval(1),
reconnectNext(0), // Index of next address for reconnecting in url.
nextFreeChannel(1),
- freeChannels(1, framing::CHANNEL_MAX),
+ freeChannels(1, 6),
connection(0),
agent(0),
listener(l),
{noformat}
Running the test with the above temporary patch, the following is observed:
{noformat}
Channel allocations from broker 6001:
3377:2020-03-06 13:29:36 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 1
3538:2020-03-06 13:29:36 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 2
3739:2020-03-06 13:29:39 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 3
3934:2020-03-06 13:29:43 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 4
4022:2020-03-06 13:29:47 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 5
4110:2020-03-06 13:29:51 [System] debug Exception constructed: Link
qpid.tcp:localhost:5001 channel pool is empty
4111:2020-03-06 13:29:51 [System] error Link qpid.tcp:localhost:5001 channel
pool is empty
4154:2020-03-06 13:29:52 [System] debug Exception constructed: Link
qpid.tcp:localhost:5001 channel pool is empty
4155:2020-03-06 13:29:52 [System] error Link qpid.tcp:localhost:5001 channel
pool is empty
4253:2020-03-06 13:29:55 [System] debug Exception constructed: Link
qpid.tcp:localhost:5001 channel pool is empty
4254:2020-03-06 13:29:55 [System] error Link qpid.tcp:localhost:5001 channel
pool is empty
4297:2020-03-06 13:29:56 [System] debug Exception constructed: Link
qpid.tcp:localhost:5001 channel pool is empty
4298:2020-03-06 13:29:56 [System] error Link qpid.tcp:localhost:5001 channel
pool is empty
...
(repeated several times more)
{noformat}
A fix which returns the channels on links that are closing to the channel pool
is suggested in attached patch BZ1748054.patch. With this patch applied
(together with the temporary pool-shrink patch above), the following is now
observed:
{noformat}
Channel allocations from broker 6001:
2020-03-06 12:20:59 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 1
2020-03-06 12:20:59 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 2
2020-03-06 12:21:02 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 3
2020-03-06 12:21:06 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 4
2020-03-06 12:21:10 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 5
2020-03-06 12:21:14 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 1
2020-03-06 12:21:18 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 3
2020-03-06 12:21:22 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 4
2020-03-06 12:21:26 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 5
2020-03-06 12:21:30 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 1
2020-03-06 12:21:34 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 3
2020-03-06 12:21:38 [Broker] debug Link qpid.tcp:localhost:5001 allocates
channel: 4
{noformat}
Channel 2 is used by a bridge which remains open
(qpid.bridge_session_amq.fanout). The channels are re-used in a cyclical
pattern, which I think is the intention.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1595) Python tests define on_modified handler when proton has none
Charles E. Rolke created DISPATCH-1595: -- Summary: Python tests define on_modified handler when proton has none Key: DISPATCH-1595 URL: https://issues.apache.org/jira/browse/DISPATCH-1595 Project: Qpid Dispatch Issue Type: Bug Components: Tests Affects Versions: 1.10.0 Reporter: Charles E. Rolke Proton python deliberately lumps modified and released dispositions into the on_released callback. There is no on_modified callback. system_tests.py and system_tests_multicast.py mistakenly add an on_modifed callback that does not override anything and is never called by proton. See https://issues.apache.org/jira/browse/PROTON-2180 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2185) Cross compilation fails during linking codec_test
[
https://issues.apache.org/jira/browse/PROTON-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Hollerer updated PROTON-2185:
---
Component/s: proton-c
Affects Version/s: proton-c-0.31.0
proton-c-0.30.0
> Cross compilation fails during linking codec_test
> -
>
> Key: PROTON-2185
> URL: https://issues.apache.org/jira/browse/PROTON-2185
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.30.0, proton-c-0.31.0
>Reporter: Franz Hollerer
>Priority: Major
>
> Target: NXP i.MX7D application processor
> Build environment_ Yocto, arm-poky-linux-gnueabi-g++ v5.2.0
> I tried to cross compile qpid-proton v0.30.0 and also the actual master
> branch. Unfortunately it fails during linking codec_test:
> {quote}Scanning dependencies of target codec_test
> [ 69%] Building CXX object cpp/CMakeFiles/codec_test.dir/src/codec_test.cpp.o
> [ 69%] Linking CXX executable codec_test
> /opt/b8mcu_sdk/0.0.1/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/real-ld:
> warning: libqpid-proton-proactor.so.1, needed by
> libqpid-proton-cpp.so.12.6.1, not found (try using -rpath or -rpath-link)
> /opt/b8mcu_sdk/0.0.1/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/real-ld:
> warning: libqpid-proton-core.so.10, needed by libqpid-proton-cpp.so.12.6.1,
> not found (try using -rpath or -rpath-link)
> libqpid-proton-cpp.so.12.6.1: undefined reference to `pn_data_put_described'
> libqpid-proton-cpp.so.12.6.1: undefined reference to `pn_dtag'
> libqpid-proton-cpp.so.12.6.1: undefined reference to `pn_message_set_reply_to'
> {quote}
> For details please see:
> *
> [http://qpid.2158936.n2.nabble.com/Cross-Compiling-qpid-proton-0-30-0-with-Yocto-SDK-tt7689081.html#a7689085]
> * [https://github.com/apache/qpid-proton/pull/187]
> I also tried to build qpid-proton with BUILD_TESTING, FUZZ_LONG_TESTS and
> FUZZ_REGRESSION__TEST set to "NO". Therefore, I wonder why it tries to build
> codec_test at all.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8424) [C++ Broker]: Better support for cross compilation
Franz Hollerer created QPID-8424:
Summary: [C++ Broker]: Better support for cross compilation
Key: QPID-8424
URL: https://issues.apache.org/jira/browse/QPID-8424
Project: Qpid
Issue Type: Improvement
Affects Versions: qpid-cpp-1.39.0, qpid-cpp-1.40.0
Reporter: Franz Hollerer
Target: NXP i.MX7 application processor
Build system: Yocto, arm-poky-linux-gnueabi-g++ v5.2.0
Unfortunately, I found that it is very hard to cross compile qpid-cpp.
First it fails with
{quote}CMake Error at src/CMakeLists.txt:84 (message):
Can't find amqp 0-10 spec for framing code generation
{quote}
This can be overcome with the patch described here:
*
[https://stackoverflow.com/questions/55953513/bitbake-build-for-qpid-cpp-1-39-0-fails]
Having solved this the build fails later on with:
{quote}[ 93%] Linking CXX executable qpid-ping
/opt/b8mcu_sdk/0.0.1/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/real-ld:
warning: libqpid-proton-core.so.10, needed by ../libqpidmessaging.so.2.0.0,
not found (try using -rpath or -rpath-link)
../libqpidmessaging.so.2.0.0: undefined reference to `pn_data_put_described'
../libqpidmessaging.so.2.0.0: undefined reference to `pn_link_free'
../libqpidmessaging.so.2.0.0: undefined reference to `pn_data_get_double'
../libqpidmessaging.so.2.0.0: undefined reference to `pn_transport_bind'
../libqpidmessaging.so.2.0.0: undefined reference to `pn_condition_is_set'
../libqpidmessaging.so.2.0.0: undefined reference to `pn_terminus_filter'
../libqpidmessaging.so.2.0.0: undefined reference to `pn_data_get_ushort'
{quote}
qpid-cpp is a great product. Please rework the build steps in order that it is
easier to cross compile it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2185) Cross compilation fails during linking codec_test
Franz Hollerer created PROTON-2185:
--
Summary: Cross compilation fails during linking codec_test
Key: PROTON-2185
URL: https://issues.apache.org/jira/browse/PROTON-2185
Project: Qpid Proton
Issue Type: Bug
Reporter: Franz Hollerer
Target: NXP i.MX7D application processor
Build environment_ Yocto, arm-poky-linux-gnueabi-g++ v5.2.0
I tried to cross compile qpid-proton v0.30.0 and also the actual master branch.
Unfortunately it fails during linking codec_test:
{quote}Scanning dependencies of target codec_test
[ 69%] Building CXX object cpp/CMakeFiles/codec_test.dir/src/codec_test.cpp.o
[ 69%] Linking CXX executable codec_test
/opt/b8mcu_sdk/0.0.1/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/real-ld:
warning: libqpid-proton-proactor.so.1, needed by libqpid-proton-cpp.so.12.6.1,
not found (try using -rpath or -rpath-link)
/opt/b8mcu_sdk/0.0.1/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/real-ld:
warning: libqpid-proton-core.so.10, needed by libqpid-proton-cpp.so.12.6.1,
not found (try using -rpath or -rpath-link)
libqpid-proton-cpp.so.12.6.1: undefined reference to `pn_data_put_described'
libqpid-proton-cpp.so.12.6.1: undefined reference to `pn_dtag'
libqpid-proton-cpp.so.12.6.1: undefined reference to `pn_message_set_reply_to'
{quote}
For details please see:
*
[http://qpid.2158936.n2.nabble.com/Cross-Compiling-qpid-proton-0-30-0-with-Yocto-SDK-tt7689081.html#a7689085]
* [https://github.com/apache/qpid-proton/pull/187]
I also tried to build qpid-proton with BUILD_TESTING, FUZZ_LONG_TESTS and
FUZZ_REGRESSION__TEST set to "NO". Therefore, I wonder why it tries to build
codec_test at all.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
