libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] syscalls name clash


From: Christian Grothoff
Subject: Re: [libmicrohttpd] syscalls name clash
Date: Fri, 18 Apr 2014 14:46:27 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

Hi!

Given that I remember Symbian also creating similar issues, I guess I'm
not opposed to this in principle.  However, we should only do this for
the symbols where it is really needed, instead of always wrapping all
system calls (and use #defines so that on platforms where the system
call is sane, we have zero overhead).

So Martin, if you could contribute
1) a patch with the minimal changes that make it work for you,
2) updates to the TeXInfo manual that describe how to make MHD
   work with lwip (so that others can benefit from the change)

I'd be in favor of merging the change.

Happy hacking!

Christian

On 04/14/14 20:29, Martin Velek wrote:
> Hi,
> 
> it is about using libmicrohttpd on non-POSIX enviroment. More users,
> more bugs discovered, and so on. I do not insist, it is only a feature
> request.
> 
> I cannot say if there is another software affected, most of it I am
> using is ANSI C or has an adaptation layer exactly from these reasons
> (non standard enviroment).
> 
> Best
> Martin
> 
> 
> 
> On Mon, Apr 14, 2014 at 2:51 PM, Zbigniew Jędrzejewski-Szmek
> <address@hidden> wrote:
>> On Mon, Apr 14, 2014 at 02:29:58PM +0200, Martin Velek wrote:
>>> Hello,
>>>
>>> could be possible to rename all socket functions (fnctl, send, accept
>>> etc) to something like MHD_FNCTL, MHD_SEND,  in further versions >
>>> 0.9.34?
>>>
>>> I am using lwip, gnu arm with newlib and there is a name clash for
>>> fnctl. The newlib has a function named fnctl, but without
>>> implementation, returning -1. The lwip has own implementation of
>>> lwip_fnctl. I cannot simply define #define fnctl lwip_fnctl because it
>>> would break all code using libmicrohttpd.
>> Hi,
>> it seems clear that the problem is in lwip, and should be fixed there. Why
>> force ugly workarounds into all other software (lib痛ttpd certainly isn't
>> the only thing affected), instead of fixing the error where it is?
>>
>> Zbyszek
>>
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]