Skip to contentSkip to conversation

proftpd does not compile

Buildroot Micha Nelissen 3 participants 7 messages Oct 4, 2008 – Oct 7, 2008

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw
Quoted 9 lines · Micha Nelissen

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?

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."
#2 lore raw
Quoted 5 lines · Nick Peirson

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:

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

#3 lore raw
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.
#4 lore raw
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.html

Not 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

#5 lore raw
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.html

Not 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_t problem is a compilation error so more problematic at this point. (The bcopy thing is "only" a compilation warning).

Micha

#6 lore raw
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