Minimum compiler and (runtime) library versions, static linking?

[gavanderhoorn]

Not too familiar with SCons, so perhaps this is glaringly obvious for someone who is, but I could not find any statements regarding minimum versions of compilers, C standards, versions of libraries and/or runtime platforms. Could you list that somewhere?

The building and running page only states gcc or clang as a compiler requirement. Which C version are you targeting?

Additionally: would this be suitable to build fully statically linked applications? Yocto is mentioned as a deployment tool, but one of my candidate platforms is not compatible with that. I do have a cross-compiler for it that can generate binaries and the platform has some support for dynamic linking, but going fully static would simplify things significantly.

[malsbat]

The versions of the various dependencies that are supported are the ones used in the automated builds. Specifically, the C compilers used are gcc 7, clang 6, and Visual Studio 2017. While not exactly a list, other platform and tool details are in the configuration scripts .travis.yml and .appveyor.yml.

Building statically linked applications should not be a problem: the build produces a static libdps.a that you can use. Also, a recently added commit adds a template for building applications with DPS.

Let me know if this is sufficient to get you going. I'd be happy to merge any changes needed to support your compiler and platform.

[gavanderhoorn]

Thanks for the clarifications.

Specifically, the C compilers used are gcc 7

I could of course just try it out, but is GCC 7 a requirement or just the defaults you use? Can you say anything about whether you are targeting C99 or are using any features added in more recent years to C? One of my targets has (unfortunately) only a really old gcc compiler, so C99 is unsupported.

Building statically linked applications should not be a problem: the build produces a static libdps.a that you can use.

Great.

Final question: can you say anything about what sort of OS services dps is using? If this is a RTFM then please tell me, but I'm mostly wondering about how it interfaces with the network stack. Is POSIX compliance just assumed, or are there explicit shims/adapters I could implement to bring up a dps stack on a not necessarily fully POSIX compliant system?

[GregBurns]

With a few minor changes DPS now compiles with –std=gnu90, it will not compile with –std=c90 (or c99) because libuv requires a non-standard pthread extension (Read/Write Locks) The patch is currently under review. At this point you will need to try building with your old gcc compiler to see if this works for you. Just uncomment the line in SConstruct that sets the –std=gnu90 flag.

Regarding POSIX dependencies, DPS uses libuv and with a couple of rare exceptions does not call the network stack APIs directly. You can take a look at SUPPORTED_PLATFORMS.md in ext/libuv for the list of platforms that libuv currently claims to support.

Greg.

From: G.A. vd. Hoorn [mailto:notifications@github.com] Sent: Thursday, August 30, 2018 8:33 AM To: intel/dps-for-iot dps-for-iot@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [intel/dps-for-iot] Minimum compiler and (runtime) library versions, static linking? (#62)

Thanks for the clarifications.

Specifically, the C compilers used are gcc 7

I could of course just try it out, but is GCC 7 a requirement or just the defaults you use? Can you say anything about whether you are targeting C99 or are using any features added in more recent years to C? One of my targets has (unfortunately) only a really old gcc compiler, so C99 is unsupported.

Building statically linked applications should not be a problem: the build produces a static libdps.a that you can use.

Great.

Finaly question: can you say anything about what sort of OS services dps is using? If this is a RTFM then please tell me, but I'm mostly wondering about how it interfaces with the network stack. Is POSIX compliance just assumed, or are there explicit shims/adapters I could implement to bring up a dps stack on a not necessarily fully POSIX compliant system?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/intel/dps-for-iot/issues/62#issuecomment-417362898, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIkg-8lbPC5FvXSrUJPmVDcHBRnIJHTHks5uWAWugaJpZM4WSCEJ.

[GregBurns]

Is there more clarification needed or can this issue be closed?

[gavanderhoorn]

No, not right now.

Thanks for all the information.

The patch is currently under review. At this point you will need to try building with your old gcc compiler to see if this works for you.

I'll try and see whether dps can be built using my old toolchain and report back. It may be a while though.

Can you say anything about the ETA of the patch that is under review? What does it change exactly?

[GregBurns]

The patch has been approved. It sets the -std=gnu90 compile flag and fixes a few C90 incompatibilities. I will close this.