Bug 238689 - math/mingw32-libgmp: depends on to-be-removed gets(3)
Summary: math/mingw32-libgmp: depends on to-be-removed gets(3)
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-18 14:46 UTC by Ed Maste
Modified: 2019-06-19 13:42 UTC (History)
1 user (show)

See Also:
cyberbotx: maintainer-feedback+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer 2019-06-18 14:46:47 UTC
I intend to remove gets(3) in the near future and this port failed in the exp-run (PR 222796)

http://package18.nyi.freebsd.org/data/112amd64PR222796-default/2018-10-27_20h58m08s/logs/errors/mingw32-libgmp-6.0.0_3.log

In file included from ../gmp.h:35:0,
                 from isfuns.cc:34:
/usr/local/mingw32/include/c++/4.8.1/cstdio:119:11: error: '::gets' has not been declared
   using ::gets;
           ^
*** Error code 1

Stop.
Comment 1 Naram Qashat 2019-06-18 15:39:36 UTC
I'm not even sure how that could be fixed. It does seem that MinGW has moved from Sourceforge to OSDN for its downloads, but I don't even use MinGW anymore. I think it isn't actually mingw32-libgmp at fault here, but MinGW as a whole, because the ports are using old files. I'd honestly rather just give up maintainership of all the mingw32 ports that I maintain, as I don't have much desire to maintain them. (I'd rather maintain MinGW-x64 but I haven't found a way to build that properly.)
Comment 2 Ed Maste freebsd_committer 2019-06-19 13:42:28 UTC
(In reply to Naram Qashat from comment #1)

It looks like mingw cstdio.h already has some support for no gets, e.g.:

#ifndef _GLIBCXX_HAVE_GETS
extern "C" char* gets (char* __s) __attribute__((deprecated));
#endif

upstream fix is probably to wrap the "using ::gets" in the same #ifdef, for the port just deleting the ::gets is probably sufficient - I suspect the consumer here is not actually using gets, it's just the reference in the header that's at fault.