I am creating a static library A which utilizes a 3rd party static library B. I want to provide a single static library which includes my code as well as the required code from library B.
I could extract all the object files from library B, but that does not heop with the problem:
Since my project is a static library project, the C/C++-Build > Settings > Tool Settings contains no linker section but an archiver section, thus there is no Miscellaneous > Other objects field as it is with executable projects. Do I miss some obvious way or do the Eclipse developers disallow such a field? Can I somehow declare to incorporate the B code?
The only alternative I currently see is to convert the project into a Makefile project.
You can add extra command line options by editing the Expert Settings: to set the Command Line pattern: to what you want. For example I can add an arbitrary extra .o file by adding it to the end of the line, as shown here:
Related
I am playing around a bit bit with Microsofts ELL library/compiler to deploy a simple learning algorithm to a micro controller. But my knowledge regarding embedded development has been better in the past. The Problem is the following:
ELL creates an LLVM IR file and a C Header file from a CNTK machine learning model (There are no pure c/c++ files). So far so good. Now I can use the IR to tell llc to make an assembler or object file for the desired target from it (ARM Cortex M4 in my case).
So I end up with a header file model.h and an assembler file model.s or an object file model.o.
Now I want to include this model with the header and the precompiled model in my embedded project.
For developing, I use the Bosch XDK, the IDE is basically Eclipse.
So, is there a way, that I can include the precompiled model in my code? When yes, how? And how do I correctly include it in Eclipse? Or do I have to do further steps? I also thought about making a static library out of the object file, but I do not have any experience on this and my tries did not end successfully so far. Thanks for your kind help.
If you make a static library from the object file, the linker will simply extract the object file and link it. That is an unnecessary step, you can add the object file to the linker command line directly. Alternatively add the .s source file to your project - the default build rules should identify it as an assembly language file and invoke the assembler rather then the compiler.
I have created a small Modelica library of my own. The way I have created it is in a single file. But I would like to make it a proper Modelica Library, as in the one with multiple directories for each subpackages.
So this is what i followed. File > New Modelica Class > Specialization - Package > Unchecked Save contents in one file. I copied the entire package code from the single file library, pasted it here and saved it. while doing so, I've noticed that the library lost most of its extends clauses, few models went missing.
Have I followed the correct procedure to create the library or did I do something wrong?
Can anyone point me towards the right direction?
#MSK, I cannot help you with OpenModelica as I work with Dymola. I did however recently split a single-file library (called package in Modelica) into several files manually. I did this so that the library hierarchy is represented in the file system hierarchy (i.e. several subfolders and .mo files in a library folder). For 35,000 lines of code this took roughly 10 hours. Just follow these steps:
create folder with same name as library
in this folder, create a text file "package.mo"
"package.mo" has to start with the statement
within ;
package [name of your package, i.e. the folder name...without the brackets];
now you want to create a subclass within this package. To do this create another folder containing a text file called "package.mo"
start this "package.mo" with
within [name of your package];
and declare the model as usual.
continue all the way down your library hierarchy
at the lowest hierarchy level you no longer need to create folders. You can simply create a .mo with the name of the lowest level class. As usual, start this file with
within [name of your package].[subclass1].[subclass2];
For an example of implementation please refer to the Physiolibrary found at https://www.modelica.org/libraries or the Modelica Standard Library which also uses this structure.
I have just one question related to Linux shared library files.
I saw lot of links related to dynamically shared library for the Linux O.S
http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html
Here in above link it is mentioned ---
include file for the library: ctest.h
Now in LINUX to use the libdl in build function --- dlopen, dlsym, dlclose.
Do we really need to include the prototype file -- ctest.h -- for dynamic lybrary ?
Please give some suggestion related to above post.
You don't really need to include the header or prototype file for the dynamic library, you do however need to at least the specific type information for the value returned by dlsym.
See here and here for examples that don't contain the include file for the dynamic library.
In the example you posted, they started off with their library functions not having header files / function prototypes, which along with providing instruction on how to avoid C++ name mangling is why they included the header file in this case.
If you define your own libraries without function prototypes, either in the source file or the header file, then you will need to include the header file when using dlsym, otherwise the inclusion of the header file of the dynamic library is unnecessary as its function prototypes were already included in the generated shared object.
The function prototypes included in header file are so that functions implemented can be resolved by name by linker. Where as the shared object file regardless of how it is linked, contains the implementation of the library which the linker links to.
The short explanation is that header files that are included with the #include are processed by the preprocessor, which means the resulting source file / files passed to the linker has knowledge of who each function call is because it looks up the function call prototype that was in the include file and has been included in the modified source. Include files tell the linker about who the function call is.
Object files, Shared Object files and other libraries files tell either the linker about what the implementation of the function call prototype does.
To answer your question in the comment, you will only have to add the libdl.so path to LD_LIBRARY_PATH or to /etc/ld.so.conf and run ldconfig, if that library or its relevant symlink hierarchy isn't in a standard location such as /usr/lib/ or /lib/.
See the following relevant StackOverflow answer answer for more information.
Further information can be found at
Program Library Howto
C Libraries Howto
Compilers, Assemblers, Linkers, Loaders: A Short Course
Linkers and Loaders
Beginner's Guide to Linkers
In Eclipse CDT, I would like to create syntax highlighting and a error parser for a custom filetype, lets say *.xy.
Those files do not contain C-Code, so i cannot use any existing parsers.
What kind of plugins would I have to create?
For the error parser, I think I have to use Codan? (have not tried it yet)
https://www.ibm.com/developerworks/java/library/j-codan/
The CDT is the wrong start for your journey, if your language is not related to the CDT supported languages and workflows. Implement an xtext based language editor instead.
Maybe this is a simple solution for you:
colorEditor plugin
You can simply add a new language by unpacking the jar archive, then adding a xyz.xml file for your .xyz files.
Pakc together again, and copy into your Eclipse "plugins" dir.
You need to introduce a new "language" - this is the extension point: http://help.eclipse.org/helios/topic/org.eclipse.cdt.doc.isv/reference/extension-points/org_eclipse_cdt_core_language.html
Codan is not an "error parser" it is a static analysis framework. Error parser processes output of the command-line tools you use to build the application (e.g. compiler, linker) to identify errors that happened during the build and filling their attributes, e.g. source file name and line number.
Codan analyzes the source code in the editor to identify errors. E.g. it checks if the variable used in the expression was declared beforehand. Note that same check can be performed by a compile at a build time and then captured by error parser and shown in the editor/problems view - the goal of Codan is to detect problems sooner, before the build is even ran. Codan can also perform some checks that compiler doesn't.
I'm using GWT in my stuff, and I would like to make it,
international, so I use GWT constants method.
I have a java file with defaults, and I now need to make properties files.
In a remember, there is a special thing to do (or done automagically) to generate
a kind of template where all constants are generated with empty labels for other langages.
Did I dream this ?
(using eclipse indigo to develop webapp with gwt but not gae)
[edit:]
this was not a dream, it's i18ncreator:
http://code.google.com/intl/fr-FR/webtoolkit/doc/latest/RefCommandLineTools.html#i18nCreator
but I can't make it working on windows :-(
[edit again ]
due to this issue : http://code.google.com/p/google-web-toolkit/issues/detail?id=5113
recommended solution is use i18ncreator in gwt 1.7 (!)
you should see the page on locales in GWT
I had the same issue. I was looking all over the place for the answer but could not find an answer; either in the docs or on stackoverflow.
So I asked in the GWT gitter channel and was told to use the compiler argument
-extra <destination-folder-name>
to generate the .properties files from the Interface files.
Steps in eclipse:
Select project you want to compile
[right click] -> Google -> GWT Compile
In the window that opens, open the Advanded options.
Add the following additional compiler argument -extra <destination-folder-name>
Compile
This should generate the *.properties files in the /destination-folder-name.
NOTE: This only generates the .properties files. It does not actually compile the application with all the locales for deploy.
Move the MyInterfaceExtension_*.properties to be right beside the MyInterfaceExtension.java file.
Make copies for each locale i.e. MyInterfaceExtension_fr_CA.properties, MyInterfaceExtension_fr_FR.properties, etc..
Translate them
Then run the compilation process again with out the -extra <destination-folder-name> option. Because it is not needed anymore.
This will compile with all the locales you enabled. You can now deploy the app the usual way.
Quick Tips:
When compiling for the first time in order to generate the .properties file, I commented out the locales in the module definition file so that the compiler will not sit there and compile again and again for every browser and every locale
i.e. supported_browser_count x enabled_locale_count = 5 browsers x 3 locales = 15 compilation Permutations, which is going to increase your compilation time.
Because, all I needed was that one *_en.properties file.
For the second compilation, after you copied and translated the properties files for each locale, you have to enable all the locales you want to support and compile.
Credits:
github #niloc132 : Colin Alworth
github #ibaca : Ignacio Baca Moreno-Torres
For helping me with this.
For my project, I used the i18n-Creator
http://code.google.com/webtoolkit/doc/latest/DevGuideI18n.html#DevGuidePropertiesFiles
It kind of does the opposite of what you are asking for. With the i18n-creator, you create the properties files for the various locales and run the script that is generated with the i18n-creator, and it will generate the constants interface.
I haven't heard yet of this feature in Eclipse but IntelliJ IDEA has this feature, you just create the Constants Interface class and the properties file. If you add a method in the class file it will warn you to add the property or the other way around. HTH.