Now i am building RIA inline application with QooXDoo. I have 2 parts in this inline app.
Now i have a problem in building parts.
How to force the generate.py to include part which is not used explicitly in Application.js
Log from generate.py source
>>> Collecting classes
- Warning: Hint: Unknown global symbol referenced: desktop (tappv3.Application:80)
- Warning: Hint: Unknown global symbol referenced: navSlideIn (tappv3.Application:88)
- Warning: Hint: Unknown global symbol referenced: setDeskTop (tappv3.Application:90)
- Warning: Hint: Unknown global symbol referenced: __MainWindow (tappv3.Application:105)
- Warning: Hint: Unknown global symbol referenced: addWindow (tappv3.MainWindow:30)
- Sorting 262 classes
>>> Assembling parts
- **part part_agent - Part #part_agent is ignored in current configuration**
- part boot
>>> Collapsing parts
>>> Verifying parts
>>> Generate application
- Processing 2 locales
- Generate packages
- Generate loader script
>>> Done (0m01.51)
Thanks in advance.
If you are referring to the part 'part_agent', this is ignored if the part doesn't contain any classes. You would need to check the part definition of this part in your config.json if it covers valid classes. You might want to review the hints about the "include" key of each part in the manual.
You should also check your "Unknown global symbol" warnings.
Related
I just found out that whenever I tried to send a build to the server I recieve ana error This is the output error :
Note: there were 4 references to unknown classes.
You should check your configuration for typos.
(http://proguard.sourceforge.net/manual/troubleshooting.html#unknownclass)
Note: there were 41 unkept descriptor classes in kept class members.
You should consider explicitly keeping the mentioned classes
(using '-keep').
(http://proguard.sourceforge.net/manual/troubleshooting.html#descriptorclass)
Note: there were 29 unresolved dynamic references to classes or interfaces.
You should check if you need to specify additional program jars.
(http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclass)
Note: there were 5 class casts of dynamically created class instances.
You might consider explicitly keeping the mentioned classes and/or
their implementations (using '-keep').
(http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclasscast)
Warning: there were 124 unresolved references to classes or interfaces.
You may need to add missing library jars or update their versions.
If your code works fine without the missing classes, you can suppress
the warnings with '-dontwarn' options.
(http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedclass)
Warning: there were 2 unresolved references to program class members.
Your input classes appear to be inconsistent.
You may need to recompile the code.
(http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedprogramclassmember)
Warning: there were 2 unresolved references to library class members.
You probably need to update the library versions.
(http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedlibraryclassmember)
Warning: Exception while processing task java.io.IOException: Please correct the above warnings first.
:transformClassesAndResourcesWithProguardForRelease FAILED
:transformClassesAndResourcesWithProguardForRelease (Thread[Daemon worker,5,main]) completed. Took 4.44 secs.
FAILURE: Build failed with an exception.
What went wrong:
Execution failed for task ':transformClassesAndResourcesWithProguardForRelease'.
java.io.IOException: Please correct the above warnings first.
The only workaround that I've found for this so far is to download and compile codenameone-maven-plugin and in src\main\java\com\codename1\maven\ComplianceCheckMojo.java at method runProguard(int passNum) add
java.createArg().setValue("-dontwarn");
on the first pass. Then use the modified version of the plugin.
Is there a (if possible standard) way to annotate a compiler output (eg object file.o, library file.a, or shared library libfile.so) with user defined attributes, for example with a json string (embedded in some section of the object file) that contains metadata for the object:
eg: as compiler (clang/gcc/dmd/ldc/gdc etc), version (eg: 2.072), whether c++11 was used, optimization and compiler flags, etc.
eg: {"compiler" : "dmd", "version" : "2.072", "flags" : "-O -debug"}
Use cases:
either the linker ld or some other user defined tool could use this metadata to give informative warnings or errors when attempting to link together several libraries whose attributes don't match (eg when linking libraries compiles with -std=c++11 with others compiled without this)
this would provide much more user friendly error messages compared to the usual hard to debug undefined symbol errors, eg: undefined reference to llvm::Twine::str[abi:cxx11]() https://github.com/ldc-developers/ldc/issues/1928 or other errors that are due to compilation flag mismatches (eg missing -debug from https://github.com/rejectedsoftware/vibe.d/issues/740#issuecomment-268039416)
make it possible for tools to read the embedded metadata and find the most appropriate matching libraries to link when multiple ones are available
NOTE: the only thing I could find was https://gcc.gnu.org/onlinedocs/gccint/LTO-object-file-layout.html but not sure if that's relevant or how I would write (and later read) such user defined attributes:
Command line options (.gnu.lto_.opts): This section contains the command line options used to generate the object files
anyone can help me?? my board is LPC1768 and the sensor is BMP180
Rebuild target 'Target 1'
compiling BMP180.c...
compiling I2C.c...
assembling startup_LPC17xx.s...
compiling system_LPC17xx.c...
compiling GPIO_LPC17xx.c...
compiling PIN_LPC17xx.c...
linking...
.\Objects\asdsa.axf: Error: L6218E: Undefined symbol main (referred from __rtentry2.o).
Not enough information to list image symbols.
Finished: 1 information, 0 warning and 1 error messages.
".\Objects\asdsa.axf" - 1 Error(s), 0 Warning(s).
Target not created.
I found the solution is easy, but before going deeper into the solution, keep in mind that C compilation unit (C Compiler and Assembler at least) compiles each pure C source file after resolving necessary pre-processor directives, and generates a relocatable object file as a result of compilation.
After the compilation unit does its job, there is another unit that is responsible for combining individually every source file that is compiled successfully into the relocatable form of one big object file for all. This unit is called Linker and the operation is called Linking
A very important feature in relocatable object file is that what is called variable, function will be noted as symbol so far. The linker has to solve the symbols, defining what is originally defined in an object file, reference what is being used in another to their original object file.
After this motivation, now we can call main() function as main() symbol.
I Found that the problem is because the source file that contains the main() function was not compiled. As a result, there is no a relocatable object file that contains the symbol corresponding to main() function. Hence, the compiler is complaining: you asked me to use (reference) a symbol you guaranteed to be found (defined) in another file but I found no such symbol!
The solution:
For Kiel IDE, to queue a source file for a compilation; you gotta shortlist it in the category "Source Group",by clicking right, either adding new files to group, or existing files to group. It will result in something like the following figure:
Now we have a main function, is turned (defined) to main symbol later, and found by the linker to reference it to whatever use it in any other relocatable object files.
I solved this problem with the following steps;
Delete your old project and create new project
Choose true library from Manage Run Time Environment like so:
Configure "Options for Target" segment. Define symbol USE_STDPERIPH_DRIVER and define project path like so:
Test your configuration. Please write the following code:
#include "stm32f10x.h" // Device header
int main() {
}
I had the same issue. The problem was that the function name in .c file had a different name with the one in the .h file, and I didn't know.
just add your c file (ex: 'main.c') to the source group (ex: 'source group 1') by expanding the target then right click on the source group, choose add existing files to group 'your source group', then choose the main.c file.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/14222.html
This should help.
Just create a dummy main() or main.c file. Linker can't find it in your pjt.
For solution only add this file C to driver folder and translate it,
Solved: This "Target Not Created" Issue was Resolved by the setting of Run Time Environment as shown in below(url) image.https://i.stack.imgur.com/kJ4IL.jpg ( consisting of CMSIS and Device supporting components in Run time environment)
{ compiling TransformFunctions.c...
linking...
Program Size: Code=768 RO-data=320 RW-data=4 ZI-data=612
FromELF: creating hex file...
".\Objects\LPC1768_B_T.axf" - 0 Error(s), 0 Warning(s).
Build Time Elapsed: 00:00:07
}
First, I know the title of the question is not the best. Likely, these concepts are well-known. Hence, let's try to be clear now.
I have a shared library(native Java agent) which can load additional shared libraries as plugins. In short, libCore.so does at load time:
H = dlopen("libPlugin1.so", RTLD_LAZY)
routine = dlsym("registration_function", H)
routine(struct Plugin)
That part is working, my problem is in the interaction between plugins and the core.
For instance, the core has a function with the name getDataFromTag. When the plugins tries to call such a function I get the following error:
java: symbol lookup error: libplugin1.so: undefined symbol: getDataFromTag
Take into account that the problem is with native code, there is no Java-Code involved in the interaction.
Now, it seems to me that the linker is not fixing the imported symbols in libPlugin1.so when I perform the dlopen. My questions are:
Do I need to declare the imported symbols in libPlugin1.so? How?
Do I need to declare the exported symbols in libCore.so? How?
Do I have to link the plugin with a dependencies to the core? How? Isn't that weird? Sort of cyclic dependencies?
Is this relate to the option -z defs? How can use that? How it does work?
Additional points, every plugin has a function with the name registration_function. So, I cannot use RTLD_GLOBAL.
I found a solution. I don't know if it is the best. Here it goes.
Do I have to link the plugin with a dependencies to the core? How? Isn't that weird? Sort of cyclic dependencies?
That's exactly what I did. I included in plugins the following linker switches:
LDFLAGS +=-L$(PATH_TO_CORE)
# Libraries we are dependent on
LIBRARIES+=-lCore
In the core library I am using RTLD_LAZY for performance and RTLD_LOCAL to avoid symbols' redefinition.
I'm pretty new to working with libraries and I'm in the process of trying to understand some specifics regarding static libraries and object files.
Summary
The behavior I'm noticing is that I can link several objects to make an executable with no problem, but if I take an intermediate step of combining those objects into static libraries, I cannot link those static libraries to make an executable without additionally specifying the needed C Run-time library in the link command.
Also, or the record, I'm doing the compiling/linking with Visual Studio 2010 from the command line. More details of the process I'm following are below.
First, let's say I have four source files in a project: main.c, util1.c, util2.c, and util3.c.
What works
I can compile these sources with the following command:cl -c main.c util1.c util2.c util3.cAs a result, I now have four object files: main.obj, util1.obj, util2.obj, and util3.obj. These object files each contain a DEFAULTLIB statement intended to inform the linker that it should additionally check the static C Run-time library libcmt.lib for any unresolved external dependencies in these object files when linking them.
I can create an executable named "app_objs.exe" by linking these objects with the following command:
link -out:app_objs.exe main.obj util1.obj util2.obj util3.obj
As mentioned in step 1, the linker used the runtime library due to the compiler's step of adding a default library statement to the objects.
Where I'm confused
Let's say I want to have an intermediate step of combining these objects into static libraries, and then linking those resulting LIB files to create my executable. First, I can create these libraries with the following commands:
link -lib -out:main.lib main.obj
link -lib -out:util.lib util1.obj util2.obj util3.obj
Now, my original thought was that I could simply link these libraries and have the same executable that I created in step 2 of "What works". I tried the following command and received linker error LNK1561, which states that an entry point needs to be specified:
link -out:app_libs.exe main.lib util.lib
From Microsoft's documentation, it is evident that linking libraries without any object files may require entry points to be specified, so I modified the command to set the subsystem as "console" to specify that the executable in intended to be a console application (which seems to imply certain entry points, thereby resolving that error):link -out:app_libs.exe -subsystem:console main.lib util.libUnfortunately, now I get a linker error stating that mainCRTStartup is an unresolved external symbol. I understand that this is defined in the C runtime library, so I can resolve this issue by manually specifying that I want to link against libcmt.lib, and this gives me a functioning executable:link -out:app_libs.exe -subsystem:console main.lib util.lib libcmt.lib
What I'm not understanding is why the default library info that the compiler placed in each object file couldn't be used to resolve the dependency on libcmt.lib. If I can link object files without explicitly stating I want libcmt.lib, and I created static libraries that are containers for the object files, why can't I link those static libraries without having to explicitly state that I want libcmt.lib? Is this just the way things are, or is there some way I could create the static libraries so that the linker will know to check for unresolved symbols in the runtime library?
Thanks for your help. If I have some fundamentally incorrect ideas here, I'd love suggestions on good references to learn all of this correctly.
Well the answer to your misunderstanding is that .lib files are often a product in themselves, and the compiler can't make those assumptions safely. That's what "external" is for.
If I produce binaries for someone's platform because its users are totally helpless, and they want/need static linkage, I have to give them foo.h and libfoo.lib without tying them to a specific runtime entry point. They may very well have defined their own entry point already for their final product, whether DLL or EXE.
You either want the runtime, or you want your own .obj that contains your entry point. Be warned that declaring and defining mainCRTStartup on your own may mean you're not executing important instructions for the target platform.