proftpd does not compile
Hi,
I am using revision 23387, and proftpd does not compile for me. It complains about redeclared mode_t in usr/include/asm/types.h vs usr/include/sys/types.h in staging_dir.
If I comment the build_i686/proftpd-1.3.1/config.h file:
#define umode_t mode_t
(to /* ... */)
then the compile is fine. Further some warnings about bcopy also, I guess:
#undef HAVE_BCOPY
should be
#define HAVE_BCOPY 1
Obviously this is not a correct patch, but not sure about correct one? Kernel headers broken? configure script broken? toolchain headers?
Please advise, thanks.
Micha
Quoted 9 lines · Micha Nelissen
Further some warnings about bcopy also, I guess:
#undef
HAVE_BCOPY
should be
#defineHAVE_BCOPY1Obviously this is not a correct patch, but not sure about correct one? Kernel headers broken? configure script broken? toolchain headers?
You need to enable UCLIBC_SUSV3_LEGACY and/or UCLIBC_SUSV3_LEGACY_MACROS (not sure exactly which combination, can anyone shed any light?) to provide bcopy, bzero, index, etc. Alternatively you can submit an upstream patch to proftpd, or patch it locally, to replace bcopy with memmove as per:
http://www.opengroup.org/onlinepubs/000095399/functions/bcopy.html
Signature · 26 lines
Regards Nick Peirson Developer Internet Central Ltd Tel: +44 (0)1782 667788 Fax: +44 (0)1782 667799 Email: nick at netcentral.co.uk Web: http://www.internet-central.net Innovation Centre Keele Science Park Keele Staffordshire ST5 5NB Registered office: Ivy House Foundry, Hanley, Stoke-on-Trent ST1 3NR Registered in England. Reg. No. 3079542 VAT Reg No. GB 655 657 108 "This communication is confidential to the addressee shown in the main text of the message. It must not be disclosed to or used by anyone other than the addressee unless disclosure is a legal requirement or has been agreed to by a separate written agreement. The company scans for but accepts no responsibility for viruses and it is the addressee's responsibility to scan attachments."
Quoted 5 lines · Nick Peirson
You need to enable
UCLIBC_SUSV3_LEGACYand/orUCLIBC_SUSV3_LEGACY_MACROS(not sure exactly which combination, can anyone shed any light?) to provide bcopy, bzero, index, etc. Alternatively you can submit an upstream patch to proftpd, or patch it locally, to replace bcopy with memmove as per:
I'm not sure if you understood me right. The problem is that bcopy is declared twice (I get a redefinition warning). It is *not* that bcopy is undefined.
If I'm wrong please correct me, thanks.
Micha
Quoted 6 lines · Micha Nelissen
I'm not sure if you understood me right. The problem is that bcopy is declared twice (I get a redefinition warning). It is *not* that bcopy is undefined.
If I'm wrong please correct me, thanks.
I think I misunderstood you. It looks like there was a patch to resolve bcopy related issues in the buildroot repository, but it was removed:
http://busybox.net/lists/buildroot/2008-June/009198.html
Not sure if it helps it would help with the issue your seeing or not?
Signature · 8 lines
Regards Nick Peirson -- Internet Central Ltd is a limited company registered in England. Registered number: 3079542. Registered office: Ivy House Foundry, Hanley, Stoke-on-Trent ST1 3NR. This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.
Quoted 5 lines · Nick Peirson
I think I misunderstood you. It looks like there was a patch to resolve bcopy related issues in the buildroot repository, but it was removed:
http://busybox.net/lists/buildroot/2008-June/009198.htmlNot sure if it helps it would help with the issue your seeing or not?
Could be but this seems to replace all bcopy uses with memcpy? That seems a workaround to me, not really solving the root problem.
Anyway, the umode_t problem is a compilation error so more problematic at this point. (The bcopy thing is "only" a compilation warning).
Micha
Quoted 9 lines · Micha Nelissen
Quoted 5 lines · Nick Peirson
I think I misunderstood you. It looks like there was a patch to resolve bcopy related issues in the buildroot repository, but it was removed:
http://busybox.net/lists/buildroot/2008-June/009198.htmlNot sure if it helps it would help with the issue your seeing or not?
Could be but this seems to replace all bcopy uses with memcpy? That seems a workaround to me, not really solving the root problem.
Using memcpy et al instead of bcopy, bzero, etc. certainly is the proper thing to do. Fix your application not to rely on legacy stuff that was _obsoleted_ (not deprecated, but really obsoleted) a decade ago.
Quoted 5 lines
Anyway, the
umode_tproblem is a compilation error so more problematic at this point. (The bcopy thing is "only" a compilation warning).Micha
Quoted 7 lines · Bernhard Reutner-Fischer
Quoted 2 lines · Micha Nelissen
Could be but this seems to replace all bcopy uses with memcpy? That seems a workaround to me, not really solving the root problem.
Using memcpy et al instead of bcopy, bzero, etc. certainly is the proper thing to do. Fix your application not to rely on legacy stuff that was _obsoleted_ (not deprecated, but really obsoleted) a decade ago.
Yes the patch is perfectly acceptable to me, but I didn't want to offend the one who removed that patch ;-). I assume there was some reason to remove it.
Micha