thanks for offering help on this. I believe GNU APL cannot do much more than
we already did (assuming the latest GNU APL now works again on BSD).
I just thought that the BSD guys might want to look into this a little further because
the code that the compiler now complains about is stone-old and worked
just fine for more than 40 years. I suspect that the root cause of all this hides
somewhere in the #include files and will, at some point in time, also affect
other projects.
i used gcc 8.4 in the past and I am almost sure that it works better. However,
C compilers have gotten more and more picky lately and I wonder how long
we will be able to keep up with the pace at which the compiler guys invent
new problems.
Best Regards,
Jürgen
On 4/13/21 12:43 PM, Alexander Shendi
wrote:
Hi Jürgen, what I can try to do, is to compile GNU APL with g++ 8.4 from ports and not with clang++ 10 (system default).Best Regards, Alexander Am 13. April 2021 12:16:09 MESZ schrieb "Dr. Jürgen Sauermann" <m...@xn--jrgen-sauermann-zvb.de>:Hi Brian, understood. However, sys/socket.h is directly #included in main.cc (line 38). The question is then why bind() and, for example, accept(), which are both declared in sys/socket.h and are both used in main.cc in behave so differently as to the need for :: and only in BSD? And why would an extern "C" wrapper around it change the behaviour in main.cc but is not needed in all other *.cc files that happily use bind() without :: ? Looking at the error message posted by Alexander: main.cc:301:8: error: value of type '<const int &, const sockaddr *, unsigned long>' is not contextually convertible to 'bool' if (bind(listen_socket, (const sockaddr *)&local, sizeof(local))) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ then apparently the compiler assumes that bind() does not return int (as declared in sys/socket.h) but something else (maybe an enum?). Or maybe it is a compiler fault? Best Regards, Jürgen On 4/13/21 2:54 AM, Callahan, Brian Robert wrote: Hi Jürgen -- Per POSIX, bind requires the inclusion of sys/socket.h, so that should be in the includes list for main.cc if there is a call to bind in main.cc. I'm not sure we can or should assume an implicit include from elsewhere. https://pubs.opengroup.org/onlinepubs/9699919799/functions/bind.html As for needing the scope-resolution on bind, that is something that someone (i.e., me or Alexander) should look further into. ~Brian _____________________________________________ Brian Robert Callahan, Ph.D. Lecturer, ITWS@RPI Office: Lally 304 _____________________________________________ From: Bug-apl [bug-apl-bounces+callab5=rpi....@gnu.org] on behalf of Dr. Jürgen Sauermann [m...@xn--jrgen-sauermann-zvb.de] Sent: Monday, April 12, 2021 5:47 AM To: Alexander Shendi; bug-apl@gnu.org Subject: Re: GNU APL now requires bash shell and in-tree builds Hi Alexander, thanks, fixed in SVN 1470. The bind() error is somewhat strange because: - in the same file (main.cc), accept() (a companion of bind()) works without :: and - in other files bind() also works without :: I suppose some other #include file declares bind() differently (which would be an error in the platform). Best Regards, Jürgen On 4/11/21 10:53 PM, Alexander Shendi wrote: Dear list, I tried out SVN 1468, but still had to modify the following files * . /configure (replace "source" with ".") * . /src/main.cc (replace "bind" with "::bind" on line 300 Thanks in advance for your help. /Alexander Am 11. April 2021 15:26:44 MESZ schrieb "Callahan, Brian Robert" <call...@rpi.edu>: Hello -- In fixing Alexander's issue, I found these lines in the GNU APL Makefile I have never seen before: buildtag.hh: Makefile buildtag.sh source ${top_srcdir}/buildtag.sh touch $@ The source command is a bash built-in and won't work on other shells, like OpenBSD ksh. Additionally, even with bash, this command does not work if doing an out-of-tree build, which is the way I have always built GNU APL and which autotools are supposed to make easy to do. Thanks. ~Brian ________________________________ Brian Robert Callahan, Ph.D. Lecturer, ITWS@RPI Office: Lally 304 -- Ceci n'est pas un courriel.-- Ceci n'est pas un courriel.
