Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot build 1.18.0 with uClibc #313

Closed
fperrad opened this issue Oct 17, 2017 · 9 comments
Closed

Cannot build 1.18.0 with uClibc #313

fperrad opened this issue Oct 17, 2017 · 9 comments
Milestone

Comments

@fperrad
Copy link
Contributor

fperrad commented Oct 17, 2017

On Buildroot, we detect build failures when using uClibc-ng, see http://autobuild.buildroot.org/?reason=libtomcrypt-1.18.0.
The build.log shows a conflict with wchar_t

In file included from ./src/headers/tomcrypt.h:88:0,
                 from src/ciphers/anubis.c:16:
./src/headers/tomcrypt_pk.h:678:17: error: conflicting types for 'wchar_t'
 typedef ulong32 wchar_t;
                 ^~~~~~~
In file included from ./src/headers/tomcrypt.h:16:0,
                 from src/ciphers/anubis.c:16:
/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/host/opt/ext-toolchain/lib/gcc/arm-buildroot-linux-uclibcgnueabi/6.3.0/include/stddef.h:328:24: note: previous declaration of 'wchar_t' was here
 typedef __WCHAR_TYPE__ wchar_t;
                        ^~~~~~~

This piece of code https://github.com/libtom/libtomcrypt/blob/develop/src/headers/tomcrypt_pk.h#L669-L680 is not suitable with uClibc.

@karel-m
Copy link
Member

karel-m commented Oct 17, 2017

Your CFLAGS:

CFLAGS="-I./src/headers -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -Os  -DLTC_SOURCE -DLTM_DESC -DLTC_NO_WCHAR"

Does the build fail if you remove -DLTC_NO_WCHAR?

@rofl0r
Copy link

rofl0r commented Oct 17, 2017

./src/headers/tomcrypt_pk.h:678:17: error: conflicting types for 'wchar_t'
typedef ulong32 wchar_t;

sounds like a pretty bad idea to define standard C types in your own headers.

quick guess, it is the result of ifdef hacks (or making ifdef hacks work) because you lack proper configure-style tests to check for properties of a certain implementation.

@fperrad
Copy link
Contributor Author

fperrad commented Oct 17, 2017

It seems the issue could be solved on Buildroot side, see https://patchwork.ozlabs.org/patch/826925/

I'll close this issue when it disappears on http://autobuild.buildroot.org

@sjaeckel
Copy link
Member

uhm, not sure though what triggered this error, but the (now) failing part is already since 1.16 in ltc...

sounds like a pretty bad idea to define standard C types in your own headers.

very true

quick guess, it is the result of ifdef hacks (or making ifdef hacks work) because you lack proper configure-style tests to check for properties of a certain implementation.

A side-note to this recurring topic: TBH a lot of my use-cases of ltc included platforms where no configure-style toolchain is easily available (AFAIK) and it always worked OOTB - that was and still is one of the strengths of all the libtom projects in my opinion.
And as already said, I'd be open to merge patches adding support for configure, cmake, whatever tool that thinks it can solve this kind of problems, but I've one side-requirement: I want to be able to build the library still OOTB resp. there have to be default-configs easily available that handle those platforms where I currently was able to throw the library sources in and build the library. (and yes... I sadly speak of stuff like the Xilinx Vivado Toolchain on Windows where not even one of the makefiles worked but at least I could create a new Xilinx-flavored Eclipse project in the src folder, set the include path and build the library...)

@karel-m
Copy link
Member

karel-m commented Oct 17, 2017

The trouble here is that LTC_NO_WCHAR sounds like "skip all wchar related parts"; however in fact it means "my system is missing wchar, try to define one".

@sjaeckel sjaeckel added this to the next milestone Oct 17, 2017
buildroot-auto-update pushed a commit to buildroot/buildroot that referenced this issue Oct 22, 2017
GCC defines wchar_t even when wchar support is disabled in uClibc. The
LTC_NO_WCHAR macro triggers a local definition of wchar_t that conflicts
with the GCC defined one. Remove LTC_NO_WCHAR to avoid that.

See also libtom/libtomcrypt#313 for more
discussion about this.

Fixes:
http://autobuild.buildroot.net/results/4ff/4ffb593185f7520d2d9a9cc988aa9c510f253930/

Cc: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
@karel-m
Copy link
Member

karel-m commented Nov 3, 2017

Can we close this?

@sjaeckel
Copy link
Member

sjaeckel commented Nov 3, 2017

well http://autobuild.buildroot.org/?reason=libtomcrypt-1.18.0 still shows failing builds

@karel-m
Copy link
Member

karel-m commented Nov 3, 2017

All those failures use -DLTC_NO_WCHAR but they shouldn't

@fperrad
Copy link
Contributor Author

fperrad commented Nov 3, 2017

On Buildroot, a fix was authored on 2017-10-17, and commited on 2017-10-22.
There is no new occurrence of this failure after the 2017-10-22.
So, it is OK for me.

@fperrad fperrad closed this as completed Nov 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants