Errors compiling applications/hub on OSX
Opened this issue · 16 comments
dpharris commented
I have been having problems compiling applications/hub on OSX.
1. src/utils/FileUtils.cxx
/Users/dpharris/openmrn/src/utils/FileUtils.cxx:111:12: error: comparison of unsigned expression < 0 is always false
[-Werror,-Wtautological-compare]
if (nr < 0) {
~~ ^ ~
1 error generated.
make[4]: *** [FileUtils.o] Error 1
make[3]: *** [build-utils] Error 2
make[2]: *** [/Users/dpharris/openmrn/targets/mach.x86/lib/timestamp] Error 2
make[1]: *** [build-mach.x86] Error 2
make: *** [build-targets] Error 2
- nr is defined as "size_t nr". I made a local fix by commenting out the offending if-block.
2. src/utils/SocketClient.hxx and .cxx ....
/Users/dpharris/openmrn/src/utils/SocketClient.hxx:630:28: error: implicit instantiation of undefined template 'std::__1::array<SocketClient::Attempt, 5>'
std::array<Attempt, 5> strategyConfig_{{
^
...
Thanks for any help.
David
balazsracz commented
The first one needs to be fixed by changing it to ssize_t from size_t.
The second is a stream of errors going back to one root cause, so looking at the errors indidivually makes no sense beyond the first one.
Could you try adding #include <array> to the top of SocketClient.hxx?
dpharris commented
- Fixed.
- Improved, but now:
In file included from /Users/dpharris/openmrn/src/openlcb/TractionCvSpace.cxx:37:
In file included from /Users/dpharris/openmrn/src/dcc/ProgrammingTrackBackend.hxx:41:
/Users/dpharris/openmrn/src/dcc/DccOutput.hxx:189:17: error: no template named 'atomic_uint8_t' in
namespace 'std'; did you mean 'atomic_init'?
static std::atomic_uint8_t outputDisableReasons_;
~~~~~^~~~~~~~~~~~~~
atomic_init
dpharris commented
I think I fixed this by;
replacing std::atomic_uint8_t
with: std::atomic<uint8_t>
at four (4) places in src/Dcc/DccOutput.hxx
I assume that this means that OSX does not have these definitions, or perhaps I am behind as I am on OSX 10.10.5.
balazsracz commented
I fixed that 11 days ago with
771e517
could you check if master compiles for you now?
dpharris commented
Hi --
I did a pull before I tried today. -- BUT I wasn't in master.
Checked out master, and did another pull.
Now error:
g++ -c -g -O0 -Wall -Werror -MD -MP -std=c++0x -m32 -fno-stack-protector
-D_GNU_SOURCE -D__STDC_FORMAT_MACROS -I./ -I/Users/dpharris/openmrn/src/
-I/Users/dpharris/openmrn/include -I/Users/dpharris/openmrn/include/mach
-MD -MF Console.d /Users/dpharris/openmrn/src/console/Console.cxx -o
Console.o
In file included from /Users/dpharris/openmrn/src/console/Console.cxx:38:
In file included from /Users/dpharris/openmrn/src/console/Console.hxx:39:
In file included from /Users/dpharris/openmrn/src/executor/Service.hxx:38:
In file included from /Users/dpharris/openmrn/src/executor/Executor.hxx:51:
*/Users/dpharris/openmrn/src/os/OSSelectWakeup.hxx:213:15: **error: **no
member named 'pselect' in the global namespace*
::pselect(nfds, readfds, writefds, exceptfds, &timeout,
&origMask_);
* ~~^*
1 error generated.
David
…On Mon, Jul 27, 2020 at 11:25 AM Balazs Racz ***@***.***> wrote:
I fixed that 11 days ago with
771e517
could you check if master compiles for you now?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#399 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEDQSVYFKNEUMOLQF5AUR3R5XBC7ANCNFSM4OWCXOJQ>
.
balazsracz commented
hm that's harder. There might be a feature test macro needed for pselect to
be visible.
This depends on the libc that your system ships with so I can't reproduce
myself (whereas a compiler i can install).
You could try
man pselect
or search in /use/include for files that declare pselect(...) and see if
there are some #ifdef's around them.
dpharris commented
Stuart --
I guess you saw the code:
#elif OPENMRN_HAVE_PSELECT
struct timespec timeout;
timeout.tv_sec = deadline_nsec / 1000000000;
timeout.tv_nsec = deadline_nsec % 1000000000;
int ret =
::pselect(nfds, readfds, writefds, exceptfds, &timeout,
&origMask_);
#elif OPENMRN_HAVE_SELECT
OSX appears to have pselect, from man:
* NAME*
*pselect* -- synchronous I/O multiplexing a la POSIX.1g
* LIBRARY*
Standard C Library (libc, -lc)
* SYNOPSIS*
*#include* *<unistd.h>*
Where is OPENMRN_FEATURE_DEVICE_SELECT defined?
David
…On Mon, Jul 27, 2020 at 1:36 PM Balazs Racz ***@***.***> wrote:
hm that's harder. There might be a feature test macro needed for pselect to
be visible.
This depends on the libc that your system ships with so I can't reproduce
myself (whereas a compiler i can install).
You could try
man pselect
or search in /use/include for files that declare pselect(...) and see if
there are some #ifdef's around them.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#399 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEDQSWCYU5HXSUHGMM53LTR5XQNBANCNFSM4OWCXOJQ>
.
dpharris commented
It has that.
#include <unistd.h>
#include "openmrn_features.h"
#include "utils/Atomic.hxx"
#include "os/os.h"
??? Why did it compile for me before?
I am stuck.
David
…On Mon, Jul 27, 2020 at 4:03 PM Mike Dunston ***@***.***> wrote:
@dpharris <https://github.com/dpharris> include/openmrn_features.h
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#399 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEDQSWYHHW2DS5YFMOXCA3R5YBSNANCNFSM4OWCXOJQ>
.
bakerstu commented
David,
I’m looking into it. For the record, I did not want OpenMRN to use pselect(). I wanted to use standard select() with a pipe for asynchronous wakeup. You know, the portable and correct way.
Thanks,
Stuart
… On Jul 27, 2020, at 7:11 PM, David Harris ***@***.***> wrote:
It has that.
#include <unistd.h>
#include "openmrn_features.h"
#include "utils/Atomic.hxx"
#include "os/os.h"
??? Why did it compile for me before?
I am stuck.
David
On Mon, Jul 27, 2020 at 4:03 PM Mike Dunston ***@***.***>
wrote:
> @dpharris <https://github.com/dpharris> include/openmrn_features.h
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#399 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAEDQSWYHHW2DS5YFMOXCA3R5YBSNANCNFSM4OWCXOJQ>
> .
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#399 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARMLDSII4KJEVFEQC47NELR5YJTLANCNFSM4OWCXOJQ>.
dpharris commented
Thanks guys.
This all came about as I wanted a functional hub, since the one in JMRI
appears to not work well.
Any suggestions on what to use as a hub? Nucleo, Tiva1294, BBB, Pi, or
stick to my laptop?
Also, it would be nice to get some interest-based routing happening in a
hub, since I am thinking that Wifi connected nodes may become more popular,
and it would be efficient not to send all traffic down their RF links. Has
anyone thought about general design and algorithms for that? Do you
centralize, or let each connection manage itself. The latter might let
multiprocessor gateways scale better?
Thanks again,
David
Thanks
David
On Mon, Jul 27, 2020 at 5:48 PM Stuart W Baker <notifications@github.com>
wrote:
… David,
I’m looking into it. For the record, I did not want OpenMRN to use
pselect(). I wanted to use standard select() with a pipe for asynchronous
wakeup. You know, the portable and correct way.
Thanks,
Stuart
> On Jul 27, 2020, at 7:11 PM, David Harris ***@***.***>
wrote:
>
>
> It has that.
>
> #include <unistd.h>
>
>
> #include "openmrn_features.h"
>
> #include "utils/Atomic.hxx"
>
> #include "os/os.h"
>
> ??? Why did it compile for me before?
>
> I am stuck.
>
> David
>
>
>
>
> On Mon, Jul 27, 2020 at 4:03 PM Mike Dunston ***@***.***>
> wrote:
>
> > @dpharris <https://github.com/dpharris> include/openmrn_features.h
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <#399 (comment)
>,
> > or unsubscribe
> > <
https://github.com/notifications/unsubscribe-auth/AAEDQSWYHHW2DS5YFMOXCA3R5YBSNANCNFSM4OWCXOJQ
>
> > .
> >
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub <
#399 (comment)>,
or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AARMLDSII4KJEVFEQC47NELR5YJTLANCNFSM4OWCXOJQ
>.
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#399 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEDQSUEXRQADHJS4J6ULIDR5YN7BANCNFSM4OWCXOJQ>
.
bakerstu commented
David,
I had to update all my X Code tools and that took a while. Not it is late and I’m going to bed. I’ll keep looking at this later.
Thanks,
Stuart
… On Jul 27, 2020, at 7:48 PM, Stuart Baker ***@***.***> wrote:
David,
I’m looking into it. For the record, I did not want OpenMRN to use pselect(). I wanted to use standard select() with a pipe for asynchronous wakeup. You know, the portable and correct way.
Thanks,
Stuart
> On Jul 27, 2020, at 7:11 PM, David Harris ***@***.*** ***@***.***>> wrote:
>
>
> It has that.
>
> #include <unistd.h>
>
>
> #include "openmrn_features.h"
>
> #include "utils/Atomic.hxx"
>
> #include "os/os.h"
>
> ??? Why did it compile for me before?
>
> I am stuck.
>
> David
>
>
>
>
> On Mon, Jul 27, 2020 at 4:03 PM Mike Dunston ***@***.*** ***@***.***>>
> wrote:
>
> > @dpharris <https://github.com/dpharris <https://github.com/dpharris>> include/openmrn_features.h
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <#399 (comment) <#399 (comment)>>,
> > or unsubscribe
> > <https://github.com/notifications/unsubscribe-auth/AAEDQSWYHHW2DS5YFMOXCA3R5YBSNANCNFSM4OWCXOJQ <https://github.com/notifications/unsubscribe-auth/AAEDQSWYHHW2DS5YFMOXCA3R5YBSNANCNFSM4OWCXOJQ>>
> > .
> >
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub <#399 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARMLDSII4KJEVFEQC47NELR5YJTLANCNFSM4OWCXOJQ>.
>
atanisoft commented
I did not want OpenMRN to use pselect().
Out of curiosity, what is the benefit of pselect() over select(), is it just the sigmask? If so, what does overriding the sigmask provide as a benefit?
balazsracz commented
pselect() is a POSIX standard function and it is portable. MacOS supports
pselect. If we are unable to write code that correctly compiles, that's
entirely our problem.
The benefit of using pselect over regular select is that it can be woken up
if a different thread desires to have the select thread resume its
operation. Making select exit early is important when you need to modify
the fd sets.
bakerstu commented
So both of these statements are untrue. Yes pselect() is an [optional] POSIX method. I’ve worked with many operating systems over the years that do not support it. Our use of pselect() unnecessarily reduces our portability.
Select can be woken up if a different thread desires it. This is typically done using a pipe.
Thanks,
Stuart
… On Jul 28, 2020, at 8:15 AM, Balazs Racz ***@***.***> wrote:
pselect() is a POSIX standard function and it is portable. MacOS supports
pselect. If we are unable to write code that correctly compiles, that's
entirely our problem.
The benefit of using pselect over regular select is that it can be woken up
if a different thread desires to have the select thread resume its
operation. Making select exit early is important when you need to modify
the fd sets.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#399 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARMLDTATWNZPPDCSJHNGZTR53FOPANCNFSM4OWCXOJQ>.
bakerstu commented
David,
I have submitted a pull request to cleanup the Mac OS X build. It removes 32-bit support and doubles down on 64-bit support.
#409 <#409>
Can you pull my branch for the Mac OS X cleanup and see if it works for you? Note that there is not currently mDNS support on Mac OS X, including in the hub. This could be added, it is just time and effort.
It seems very likely that there is a linger race condition with using pselect() on Mac OS X. I have filed an issue about pselect().
#410 <#410>
I remember expressing this concern about pselect() at the time the change was made. Here is the commit where we made the change:
b09ba70 <b09ba70>
Thanks,
Stuart
… On Jul 28, 2020, at 8:30 AM, Stuart Baker ***@***.***> wrote:
So both of these statements are untrue. Yes pselect() is an [optional] POSIX method. I’ve worked with many operating systems over the years that do not support it. Our use of pselect() unnecessarily reduces our portability.
Select can be woken up if a different thread desires it. This is typically done using a pipe.
Thanks,
Stuart
> On Jul 28, 2020, at 8:15 AM, Balazs Racz ***@***.*** ***@***.***>> wrote:
>
>
> pselect() is a POSIX standard function and it is portable. MacOS supports
> pselect. If we are unable to write code that correctly compiles, that's
> entirely our problem.
>
> The benefit of using pselect over regular select is that it can be woken up
> if a different thread desires to have the select thread resume its
> operation. Making select exit early is important when you need to modify
> the fd sets.
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub <#399 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARMLDTATWNZPPDCSJHNGZTR53FOPANCNFSM4OWCXOJQ>.
>