Comments (31)
ibc
commented on August 27, 2024
BTW may I understand why a C library overrides standard types? If so, why does not it define its own types srtp_uint64_t?
from libsrtp.
jfigus
commented on August 27, 2024
I'm not seeing this issue in Ubuntu (based on Debian) using gcc 4.8.2. What's the value of the following in your config.h:
/* Define to 1 if the system has the type `uint64_t'. */
#define HAVE_UINT64_T 1
/* Define to 1 if you have the <stdint.h> header file. */
#define HAVE_STDINT_H 1
from libsrtp.
ibc
commented on August 27, 2024
My crypto/include/config.h has 1 for both defines.
from libsrtp.
ibc
commented on August 27, 2024
Regardless ./configure does not produce the above error in Debian, the fact is that if later I include srtp.h in my project I get the error reported in the issue description.
BTW, in Debian I get also errors in config.log (I just show those related to uint64 stuff):
- Debian 64 bits (gcc 4.7.2):
configure:4475: result: yes
configure:4484: checking for uint64_t
configure:4484: gcc -c -fPIC -Wall -O4 -fexpensive-optimizations -funroll-loops conftest.c >&5
configure:4484: $? = 0
configure:4484: gcc -c -fPIC -Wall -O4 -fexpensive-optimizations -funroll-loops conftest.c >&5
conftest.c: In function 'main':
conftest.c:75:23: error: expected expression before ')' token
configure:4484: $? = 1
- OSX (clang 6.0):
onfigure:4485: result: yes
configure:4494: checking for uint64_t
configure:4494: gcc -c -fPIC -Wall -O4 -fexpensive-optimizations -funroll-loops conftest.c >&5
clang: warning: -O4 is equivalent to -O3
configure:4494: $? = 0
configure:4494: gcc -c -fPIC -Wall -O4 -fexpensive-optimizations -funroll-loops conftest.c >&5
clang: warning: -O4 is equivalent to -O3
conftest.c:75:23: error: expected expression
if (sizeof ((uint64_t)))
^
1 error generated.
configure:4494: $? = 1
Anyhow, inIn both cases (Debian and OSX) the resulting crypto/include/config.h after calling ./configure includes:
#define HAVE_UINT64_T 1
#define HAVE_STDINT_H 1
from libsrtp.
jfigus
commented on August 27, 2024
If that's the case, then NO_64BIT_MATH shouldn't be defined, in which case the following code should not be brought in by the preprocessor. But this is where you're getting the redefinition error. Are you setting NO_64BIT_MATH somewhere else in your project?
#ifdef NO_64BIT_MATH
typedef double uint64_t;
/* assert that sizeof(double) == 8 */
extern uint64_t make64(uint32_t high, uint32_t low);
extern uint32_t high32(uint64_t value);
extern uint32_t low32(uint64_t value);
#endif
from libsrtp.
ibc
commented on August 27, 2024
No, I do not define that. But, I think the problem is in crypto/include/integers.h line 77:
/* Can we do 64 bit integers? */
#ifndef HAVE_UINT64_T
# if SIZEOF_UNSIGNED_LONG == 8
typedef unsigned long uint64_t;
# elif SIZEOF_UNSIGNED_LONG_LONG == 8
typedef unsigned long long uint64_t;
# else
# define NO_64BIT_MATH 1
# endif
There NO_64BIT_MATH is set.
Note also this:
in libsrt/ p$ grep -r NO_64BIT_MATH *
crypto/kernel/key.c:#ifdef NO_64BIT_MATH
crypto/kernel/key.c:#ifdef NO_64BIT_MATH
crypto/kernel/key.c:#ifdef NO_64BIT_MATH
crypto/test/env.c:#ifndef NO_64BIT_MATH
crypto/cipher/aes_icm.c:#ifdef NO_64BIT_MATH
crypto/cipher/aes_icm.c:#ifdef NO_64BIT_MATH
crypto/replay/rdbx.c:#ifdef NO_64BIT_MATH
crypto/replay/rdbx.c:#ifdef NO_64BIT_MATH
crypto/replay/rdbx.c:#ifdef NO_64BIT_MATH
crypto/replay/rdbx.c:#ifdef NO_64BIT_MATH
crypto/replay/rdbx.c:#ifdef NO_64BIT_MATH
crypto/replay/rdbx.c:#ifdef NO_64BIT_MATH
crypto/replay/rdbx.c:#ifdef NO_64BIT_MATH
crypto/replay/rdbx.c:#ifdef NO_64BIT_MATH
crypto/replay/rdbx.c:#ifdef NO_64BIT_MATH
crypto/include/integers.h:# define NO_64BIT_MATH 1
crypto/include/integers.h:#ifdef NO_64BIT_MATH
crypto/include/datatypes.h:/* ok for NO_64BIT_MATH if it can compare uint64_t's (even as structures) */
crypto/include/datatypes.h:#ifdef NO_64BIT_MATH
crypto/include/datatypes.h:# ifdef NO_64BIT_MATH
srtp/srtp.c:#ifdef NO_64BIT_MATH
srtp/srtp.c:#ifdef NO_64BIT_MATH
srtp/srtp.c:#ifdef NO_64BIT_MATH
srtp/srtp.c:#ifdef NO_64BIT_MATH
srtp/srtp.c:#ifdef NO_64BIT_MATH
srtp/srtp.c:#ifdef NO_64BIT_MATH
srtp/srtp.c:#ifdef NO_64BIT_MATH
srtp/srtp.c:#ifdef NO_64BIT_MATH
srtp/srtp.c:#ifdef NO_64BIT_MATH
srtp/srtp.c:#ifdef NO_64BIT_MATH
srtp/srtp.c:#ifdef NO_64BIT_MATH
srtp/srtp.c:#ifdef NO_64BIT_MATH
srtp/srtp.c:#ifdef NO_64BIT_MATH
srtp/srtp.c:#ifdef NO_64BIT_MATH
from libsrtp.
ibc
commented on August 27, 2024
BTW:
include/srtp.hincludessrtp_priv.hwhich- includes
crypto/include/crypto_kernel.hwhich - includes
crypto/include/cipher.hwhich - includes
crypto/include/datatypes.hwhich - includes
crypto/include/integers.h.
So at the end when I include "srtp.h" into my project that header also includes libsrtp's "integers.h" which looks for HAVE_UINT64_T, HAVE_SYS_TYPES_H, etc etc.
This is wrong, right? This is, "srtp.h" should NOT include "integers.h".
from libsrtp.
ibc
commented on August 27, 2024
BTW: could libsrtp use SRTP_ macro prefixes everywhere? could it also rename err_status_t (which is 100% generic) to srtp_err_status_t?
from libsrtp.
jfigus
commented on August 27, 2024
That's interesting. The section of integers.h in my code looks like:
/* Can we do 64 bit integers? */
#ifndef HAVE_UINT64_T
#if SIZEOF_UNSIGNED_LONG == 8
typedef unsigned long uint64_t;
#elif SIZEOF_UNSIGNED_LONG_LONG == 8
typedef unsigned long long uint64_t;
#else
#define NO_64BIT_MATH 1
#endif
#endif
from libsrtp.
ibc
commented on August 27, 2024
Well, that is the source code of integers.h so yes, mine looks exactly the same :)
from libsrtp.
jfigus
commented on August 27, 2024
And since you have HAVE_UINT64_T=1, it's not clear to me how NO_64BIT_MATH is set in your project. Just for fun, can you change the following code in integers.h:
from:
#ifdef NO_64BIT_MATH
typedef double uint64_t;
/* assert that sizeof(double) == 8 */
extern uint64_t make64(uint32_t high, uint32_t low);
extern uint32_t high32(uint64_t value);
extern uint32_t low32(uint64_t value);
#endif
to:
#if defined(NO_64BIT_MATH) && !defined(HAVE_UINT64_T)
typedef double uint64_t;
/* assert that sizeof(double) == 8 */
extern uint64_t make64(uint32_t high, uint32_t low);
extern uint32_t high32(uint64_t value);
extern uint32_t low32(uint64_t value);
#endif
from libsrtp.
ibc
commented on August 27, 2024
Same issue when compiling my project:
In file included from /usr/local/include/srtp/srtp.h:53:
In file included from /usr/local/include/srtp/crypto_kernel.h:49:
In file included from /usr/local/include/srtp/rand_source.h:49:
In file included from /usr/local/include/srtp/err.h:49:
In file included from /usr/local/include/srtp/datatypes.h:50:
/usr/local/include/srtp/integers.h:103:16: error: typedef redefinition with different types ('double' vs 'unsigned long long')
typedef double uint64_t;
^
/usr/include/_types/_uint64_t.h:31:28: note: previous definition is here
typedef unsigned long long uint64_t;
from libsrtp.
jfigus
commented on August 27, 2024
Is your project open source? I'd like to try compiling it myself to reproduce the problem. I tried on a 64-bit and 32-bit systems, no luck reproducing here. You indicated earlier the way to reproduce is to include stdint.h in the application using libsrtp. I try this by modifying test/rtpw.c to include stdint.h. So far there's no issue on my systems. Does rtpw.c compile for you if you include stdint.h?
from libsrtp.
ibc
commented on August 27, 2024
The project is not yet opensource and I prefer to simplify the issue. Let me try I will come back with some code.
from libsrtp.
ibc
commented on August 27, 2024
This seems a different issue, but I think it has some relationship.
srtp_bug.c:
#include <srtp/srtp.h>
int main(int argc, char* argv[]) {
return 0;
}
Debian Wheezy 64 bits
(some happens in OSX with clang)
$ gcc --version
gcc (Debian 4.7.2-5) 4.7.2
$ gcc -Wall -I/usr/local/include -L/usr/local/lib -lsrtp -o srtp_bug srtp_bug.c
In file included from /usr/local/include/srtp/datatypes.h:51:0,
from /usr/local/include/srtp/err.h:49,
from /usr/local/include/srtp/rand_source.h:49,
from /usr/local/include/srtp/crypto_kernel.h:49,
from /usr/local/include/srtp/srtp.h:53,
from srtp_bug.c:1:
/usr/local/include/srtp/alloc.h:52:14: error: unknown type name ‘size_t’
from libsrtp.
ibc
commented on August 27, 2024
If you compile with g++ it also fails somewhere else:
/usr/local/include/srtp/datatypes.h:421:29: error: ‘htonl’ was not declared in this scope
from libsrtp.
ibc
commented on August 27, 2024
Ok, here we go:
srtp_bug_2.c:
#include <stddef.h> // size_t
#include <stdint.h> // uint8_t, etc
#include <srtp/srtp.h>
int main(int argc, char* argv[]) {
return 0;
}
Debian and OSX
$ gcc -Wall -I/usr/local/include -L/usr/local/lib -lsrtp -o srtp_bug srtp_bug_2.c
In file included from /usr/local/include/srtp/datatypes.h:50:0,
from /usr/local/include/srtp/err.h:49,
from /usr/local/include/srtp/rand_source.h:49,
from /usr/local/include/srtp/crypto_kernel.h:49,
from /usr/local/include/srtp/srtp.h:53,
from srtp_bug_2.c:3:
/usr/local/include/srtp/integers.h:102:16: error: conflicting types for ‘uint64_t’
In file included from /usr/lib/gcc/x86_64-linux-gnu/4.7/include/stdint.h:3:0,
from srtp_bug.c:2:
/usr/include/stdint.h:56:27: note: previous declaration of ‘uint64_t’ was here
If you remove the #include <stdint.h> line then it compiles, but...
from libsrtp.
jfigus
commented on August 27, 2024
What happens for you when you add the additional include shown below...
#include <stddef.h> // size_t
#include <stdint.h> // uint8_t, etc
#include <srtp/config.h>
#include <srtp/srtp.h>
int main(int argc, char* argv[]) {
return 0;
}
from libsrtp.
ibc
commented on August 27, 2024
Sorry, I cannot see you includes if they are enclosed between < and >. Please enclose your code as follows:
` ` ` <--- without spaces
code
` ` ` <--- without spaces
from libsrtp.
jfigus
commented on August 27, 2024
Add an include to srtp/config.h prior to srtp/srtp.h in srtp_bug2.c
While you shouldn't have to include config.h, it should resolve the problem. I'm looking at how to solve this problem properly. I'm not sure there will be a simple solution. The include hierarchy in libsrtp is a mess and needs refactoring.
from libsrtp.
ibc
commented on August 27, 2024
Yes, that "fixes" the issue. However theoretically 8376a64 was about removing config.h from the public header, so having to manually include it in any project using libsrtp seems not very cool :)
from libsrtp.
ibc
commented on August 27, 2024
Would you accept a pull request prefixing ALL the macros with "SRTP_"?
from libsrtp.
jfigus
commented on August 27, 2024
No argument from me regarding including config.h. I just wanted to see if you hit any other issues after moving beyond the integers.h problem. I'll take a look at resolving the problem properly. Currently libsrtp installs way too many header files into /usr/local. Most of these header files should be private. But it may require major refactoring to the data structures to resolve this properly.
Regarding the SRTP_ macro, we'll have to think about backwards compatibility on that. It seems that backwards compatibility continues to be an issue with various issues being raised. I'm wondering if it's time for some major refactoring to address these various issue and bumping the version# of the library. Downstream projects that don't want to move forward can stay on the old code. But this would allow us to move past these issues for folks that want to move forward.
from libsrtp.
jfigus
commented on August 27, 2024
I just committed a quick work-around into master. Please let me know if this doesn't work for you.
from libsrtp.
ibc
commented on August 27, 2024
It does not fix it at all. Commented on the commit:
from libsrtp.
jfigus
commented on August 27, 2024
The commit 45ab533 should resolve the issue. I've confirmed this works on Linux using both gcc and clang. Let me know if it's still broken in your environment.
from libsrtp.
ibc
commented on August 27, 2024
It does not work with C++:
- srtp_bug.cpp:
#include <srtp/srtp.h>
int main(int argc, char* argv[]) {
return 0;
}
- GCC 4.9 in OSX:
g++-4.9 -std=c++11 -Wall -I/usr/local/include -L/usr/local/lib -lsrtp -o srtp_bug srtp_bug.cpp
n file included from /usr/local/include/srtp/err.h:49:0,
from /usr/local/include/srtp/rand_source.h:49,
from /usr/local/include/srtp/crypto_kernel.h:49,
from /usr/local/include/srtp/srtp.h:55,
from srtp_bug.cpp:4:
/usr/local/include/srtp/datatypes.h: In function 'uint64_t be64_to_cpu(uint64_t)':
/usr/local/include/srtp/datatypes.h:421:28: error: 'low32' was not declared in this scope
v = make64(htonl(low32(v)),htonl(high32(v)));
^
/usr/local/include/srtp/datatypes.h:421:29: error: 'htonl' was not declared in this scope
v = make64(htonl(low32(v)),htonl(high32(v)));
^
/usr/local/include/srtp/datatypes.h:421:45: error: 'high32' was not declared in this scope
v = make64(htonl(low32(v)),htonl(high32(v)));
^
/usr/local/include/srtp/datatypes.h:421:47: error: 'make64' was not declared in this scope
v = make64(htonl(low32(v)),htonl(high32(v)));
^
- GCC 4.7.2 in Debian 64 bits
g++-4.9 -std=c++11 -Wall -I/usr/local/include -L/usr/local/lib -lsrtp -o srtp_bug srtp_bug.cpp
In file included from /usr/local/include/srtp/err.h:49:0,
from /usr/local/include/srtp/rand_source.h:49,
from /usr/local/include/srtp/crypto_kernel.h:49,
from /usr/local/include/srtp/srtp.h:55,
from srtp_bug.cpp:4:
/usr/local/include/srtp/datatypes.h: In function ‘uint64_t be64_to_cpu(uint64_t)’:
/usr/local/include/srtp/datatypes.h:421:28: error: ‘low32’ was not declared in this scope
/usr/local/include/srtp/datatypes.h:421:29: error: ‘htonl’ was not declared in this scope
/usr/local/include/srtp/datatypes.h:421:45: error: ‘high32’ was not declared in this scope
/usr/local/include/srtp/datatypes.h:421:47: error: ‘make64’ was not declared in this scope
Basically those functions make64, high32 and low32 should be always defined by srtp/integers.h, but they are NOT due:
#if defined(NO_64BIT_MATH) && defined(HAVE_CONFIG_H)
typedef double uint64_t;
/* assert that sizeof(double) == 8 */
extern uint64_t make64(uint32_t high, uint32_t low);
extern uint32_t high32(uint64_t value);
extern uint32_t low32(uint64_t value);
#endif
And of course, #include <arpa/inet.h> is needed for htonl.
from libsrtp.
jfigus
commented on August 27, 2024
ef53505 should resolve this failure.
from libsrtp.
ibc
commented on August 27, 2024
Confirmed. It works in both OSX and Linux with clang, clang++, gcc, g++.
from libsrtp.
jfigus
commented on August 27, 2024
Closing this issue for now since it appears to be resolved. Thanks for your help.
from libsrtp.
ibc
commented on August 27, 2024
Sure, thanks a lot.
from libsrtp.
Related Issues (20)
- unresolved external symbol srtp_crypto_policy_set_aes_cm_192_hmac_sha1_80 when linking lib on windows HOT 2
- Writeup of the when Openssl is required, and which operations/modes are affected? HOT 4
- support ubuntu-22.04 in github workflow HOT 2
- check if libdl and libz are really needed HOT 1
- New release would be appreciated HOT 3
- Usecase Question about libsrtp HOT 1
- Hash of v2.4.2 tarball has changed HOT 4
- srtp_create fails if setting up RTP encryption with AES-128-GCM and not specifying RTCP encryption HOT 2
- Implementation of custom encryption algorithm HOT 1
- Performance issue with OpennSSL 3 and libsrtp HOT 9
- Build fails on macOS -Wshorten-64-to-32 HOT 2
- How to compile libsrtp2.3.0 with AES-GCM cipher group support ? HOT 1
- Cross-compile libsrtp to Windows (64-bit) is failing given that OpenSSL can't be found HOT 1
- When is safe to use srtp_remove_stream? HOT 2
- Bad link in README.md HOT 1
- Release Version 3.0.0 HOT 3
- Use consistent types through out code base HOT 1
- Review public API
- libsrtp + openssl + certificates HOT 2
- remove NO_64BIT_MATH code
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libsrtp.