5

since a couples of days I am trying to write a Haxe hxcpp wrapper for linenoise which is programmed in C code; the library is very simple and the header also contains an extern C. I am following the snowkit linc macro template but I can't get a way to compile the C module and that it links with the rest of the project, I am not sure how to continue.

I have no problems to compile the code as a C object and link it with a C executable in my system (OSX el Capitan) so I assume I am doing something wrong in my haxe project, perhaps I can't really link hxcpp with a C library using directly the build process from haxe or I should pipe it manually by writing per hand the commands.

@:keep
@:structAccess
@:include('linenoise.h')
#if !display
@:build(linc.Linc.touch())
@:build(linc.Linc.xml('linenoise'))
#end

extern class LineNoise {
 @:native("linenoiseClearScreen")
 static function linenoiseClearScreen(): Void;
} //LineNoise

Recently I am getting this error:

g++ -o Test-debug -stdlib=libstdc++ -framework Cocoa -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -m64 @/Users/vresko/projects/linenoise/test/cpp/obj/darwin64-debug/all_objs 

Undefined symbols for architecture x86_64: 

 "_linenoiseClearScreen", referenced from: 

 Test_obj::main() in ab184b9a_Test.o 

ld: symbol(s) not found for architecture x86_64 

clang: error: linker command failed with exit code 1 (use -v to see invocation)

I am aware that this error has several mentions, but I am not sure how to solve that within the context of haxe hxcpp.

If I use a C++ wrapper including the hxcpp.h as the typical linc example does the error is still the same, and the function I am declaring here (linenoiseClearScreen) is actually a trivial print statement .

I also read about other possibilities such as CFFI for neko to create a wrapper around the library (I may have read everything on the internet about it) but I wanted to keep the code static linked if possible and compatible with all hxcpp targets.

Víctor R. Escobar
  • 415
  • 3
  • 12
  • 1
    it would be much easier to use: `#ifdef _cplusplus extern C { #dendif #include #ifdef _cplusplus } #endif – user3629249 Dec 09 '15 at 03:38
  • 1
    The [linenoise.h](https://github.com/antirez/linenoise/blob/master/linenoise.h#L42) has already that surrounding, I suppose I should be able to compile it as C++ but when I do then I get additional errors (like error by assigning a void pointer to char pointer and so on); that would require me to modify the original lib which I would like to avoid in order to keep the wrapper working with a vanilla library. I wonder if there is an additional option for that. – Víctor R. Escobar Dec 09 '15 at 07:57
  • 1
    However when I use the haxe compiler I never met those last errors related to the C types in C++; the haxe compiler never seems to try to compile my C library – Víctor R. Escobar Dec 09 '15 at 08:01
  • 1
    what is the `haxe` compiler and where can it be found? – user3629249 Dec 09 '15 at 10:38
  • 1
    Haxe is a programming language that is translated to C++ and other targets. I want to write a wrapper in Haxe for the linenoise C library. Haxe web: http://haxe.org – Víctor R. Escobar Dec 09 '15 at 18:16

1 Answers1

6

sounds like you are missing a step when setting up your dependencies for hxcpp, in your case linenoise. hxcpp doesnt know about the .c-file.

This is obviously missing in the empty template since there is no actual dependency used.

Anyway, i'm the author of https://github.com/snowkit/linc_enet, the binding for ENet for hxcpp. It might help you to compare your setup to a more complete example like this.

In this case, ENet, as a dependency, is setup as a special hxcpp git submodule inside the lib-folder. It can be found here as part of the native-toolkit: https://github.com/native-toolkit/enet

What you should look at are the 2 xml-files defines.xml and files.xml. They basically describe the dependency for hxcpp. you can literally copy'n paste those, adapt the defines and list of files for linenoise.

Also, I wouldnt recommend including linenoise.h directly via @:include in the binding. Linc-libraries use an indirection at this level(see the linc-folder in the linc_enet-root) to allow for extensions/helpers of/for the binding on the C++-side without touching the actual dependencies.

If you follow that concept see linc/linc_enet.xml where everything is tied together for compilation.

Michael Bickel
  • 96
  • 2
  • As soon as I added the C file to the XML as you pointed in your example it worked :D It was enough with that: Once it solved it looks so simple that it is almost ashaming to not find it by myself. Where did you find those information about the compiler? Especially all those XML inputs? With Haxe I always have the problem of not finding the information. When it is finished I will submit it to your linc project :) – Víctor R. Escobar Dec 10 '15 at 22:53
  • 2
    I have been using Haxe since 2009 and over time I kinda got used to having little to no documentation. It was pretty frustrating at times. In the end i studied [Hugh Sanderson's blog](http://gamehaxe.com/tag/hxcpp)(author of hxcpp) and hxcpp itself, which is really just a neko-script parsing and setting up the inputs for the compile. It's not that complex once you drill into it. For the future you might want to check out the gitter-channels of Haxe and the snowkit-collective(snowkit.org). There are lots of helpfull Haxers there. – Michael Bickel Dec 11 '15 at 11:16
  • Studying the source code is the ultimate learning experience, agreed. That might be a fun side project for getting into C++, as well. However, it's not an excuse for bad documentation. – FullOfCaffeine Dec 11 '15 at 20:53
  • Merely stating the facts of _my_ learning experience here. Also, no excuse was made. Obviously there are better practices but reality can be a harsh place. Especially when you need to get things done. – Michael Bickel Dec 11 '15 at 23:04
  • Víctor R. Escobar, FullOfCaffeine and @MichaelBickel I'll update the empty example to include it's c++ file and I'll add a few commented sections for quicker hints. It's also worth noting that you should post these issues on the linc repo, that's the place to find help most directly so others can find it too :) – underscorediscovery Feb 04 '16 at 01:12