If I link against ecereCOM it is much more in line with what I want:ldd obj/release.linux/httpServer /lib/ld-musl-i386.so.1 (0x507bc000) libecereCOM.so.0 => /usr/lib/libecereCOM.so.0 (0x50759000) libc.musl-x86.so.1 => /lib/ld-musl-i386.so.1 (0x507bc000)

But it segfaults when I try to run it.What is the proper way to make a non-gui app that uses the network capabilities of ecere ?

At this point in time, the networking functionality is only included within the libecere library, which also includes the GUI stuff and unfortunately has a dependency on the X libraries.

The libecereCOM only includes the very minimal stuff for the eC runtime.

As part of our 2017 roadmap, we have plans to address that and split libecere into multiple libraries with minimal dependencies.

In the meantime however there is no easy way to split the GUI from the networking. However, it should be easy enough to build a networking library without the X dependencies by only including the NCurses interface (ecere/src/gui/drivers/NCursesInterface.ec) and graphics driver (ecere/src/gfx/drivers/NCursesDisplayDriver.ec), and omitting the X11 ones (ecere/src/gui/drivers/XInterface.ec and ecere/src/gfx/drivers/XDisplayDriver.ec). It would require some .epj projects and/or Makefiles tweaks, and possibly some #ifdef's in the source code as well.

You should still inherit from 'GuiApplication' rather than 'Application' however, as the network processing loop is part of the GuiApplication class. We hope to fix that as well.

If you don't want to bring up even an NCurses terminal window to keep the app running, you can simply override GuiApplication::Main() and run a loop that will call the 'WaitNetworkEvent()' and 'ProcessNetworkEvents()' methods.

Sorry for the late reply, been especially busy this last week. Please let me know if you run into further issues or have any further questions.

The compiler needs a dynamic version of the library when compiling modules making use of them. However it is possible to link the final application with static versions of them. To build static versions of libecere, use either the the 'static' or the 'vanilla' configuration that you will find in ecere.epj (vanilla should already be pre-compiled/installed in the lib/ folder as libecereVanilla.a). Vanilla is kept smaller by excluding 3D graphics, a number of bitmap formats and display drivers. You can of course customize a configuration with exactly what you would like to include. Likewise, libecereCOM has a 'static' configuration.

To link your application statically, it will need to import the library as such:import static "ecere"Often we use a pre-processor definition to have the option to link statically or not:

import ECERE_STATIC "ecere"

Where ECERE_STATIC is either nothing or 'static'.

And then the static version of the library you wish to use must be specified in the Project Settings/Linker Options. Additinally, all libecere dependencies must be linked with directly in your application, and resources added to the 'libecere' library must then be included within your project's resources under an 'ecere' folder.

Alternatively you can use WriteJSONObject() and JSONParser() to save to / retrieve from JSON. ECON aims to be a super set of JSON, but there are further restrictions on identifiers to be able to save as ECON (e.g. valid eC identifiers for 'keys').

There are no samples yet showing how to use it but you can find example of it in the Ecere IDE's source code.