search

SymbiSoft / mosync

Automatically exported from code.google.com/p/mosync
0 stars 0 forks source link

Pipe tool fails when building from command line #1085

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Create two MoSync projects: a static library project X and a moblet project 
Y. Let Y depend on X.
2. Try to build Y from command line ==> error. (If Y is independent ==> no 
error).

What is the expected output? What do you see instead?
The expected output is a phone binary but pipe tool fails. A log file is 
attached.

What version of the product are you using? On what operating system?
MoSync-2.4.0-r2425.exe, Windows XP

Please provide any additional information below.
set MOSYNC=C:\MoSync
set MOSYNCC=%MOSYNC%\eclipse\mosyncc.exe
set MOSYNC_WORKSPACE=%MOSYNC%\workspace
set MOSYNC_PROJECT=Y
echo begin HTC/Hero end> finalizer.txt
%MOSYNCC% -application com.mobilesorcery.sdk.builder.headless -data 
%MOSYNC_WORKSPACE% -project %MOSYNC_PROJECT% -f finalizer.txt

Original issue reported on code.google.com by anders.d.olofsson@gmail.com on 20 Apr 2011 at 11:27

Attachments:

GoogleCodeExporter commented 8 years ago 
I'd like to see the console log, which should contain pipe-tool's error 
messages. The attached Eclipse log doesn't have them.

Original comment by fredrik....@gtempaccount.com on 20 Apr 2011 at 11:40

GoogleCodeExporter commented 8 years ago 
I can build my project successfully from the IDE so it seems like the pipe
tool looks for the libs in the wrong place (in the workspace perhaps?) when
building from command line.

c:\MoSync\bin\pipe-tool.exe -appcode=SYRD -stabs=stabs.tab -heapsize=131072
-stacksize=65536 -datasize=524288 -sld=sld.tab -sc:\MoSync\lib\pipe
-s..\..\..\libomds\Output\Release -s..\..\..\libom\Output\Release
-s..\..\..\libec3shared\Output\Release -s..\..\..\libtommath\Output\Release
-s..\..\..\libtomcrypt\Output\Release -sC:\MoSync\lib\newlib_release -B
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\program
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\main.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\Version.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\Util.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\ScreenController.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\PrimitiveScreen.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\PinScreen.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\PersonalizationScreen
.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\PersistentStorage.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\PasswordInputField.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\OnScreenKeyboard.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\om.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\NumericalInputField.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\MessageBoxScreen.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\Menu.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\MainMenuScreen.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\HttpPersonalizer.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\Http.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\EntropyCollector.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\CodeScreen.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\CodeGeneratorData.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\CodeGenerator.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\ChallengeScreen.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\ChallengeInputField.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\BaseScreen.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\Appearance.s
C:\Svn\ec3-trunk\om\mosync\om\FinalOutput\Release\HTC\Hero\AmountInputField.s
MAUtil.lib MAUI.lib libomds.lib libom.lib libec3shared.lib libtommath.lib
libtomcrypt.lib newlib.lib
failed to load 'libomds.lib'

Original comment by anders.d.olofsson@gmail.com on 20 Apr 2011 at 12:26

GoogleCodeExporter commented 8 years ago 
It's probably more likely that Eclipse forgets to put in the correct parameters 
to pipe-tool on the command line.

Is libomds.lib the only library that fails to load? Is it also the only one you 
have that kind of dependency on?

Original comment by fredrik....@gtempaccount.com on 20 Apr 2011 at 12:44

GoogleCodeExporter commented 8 years ago 
Libomds is the only library that fails to load according to the error
message. Perhaps pipe tool never tries to load the other libraries after
detecting that the first lib (libomds) could not be loaded, though, I don't
know. I have dependencies to other libs as well.

Original comment by anders.d.olofsson@gmail.com on 20 Apr 2011 at 12:53

GoogleCodeExporter commented 8 years ago 
All right, we'll try to reproduce the bug.

Original comment by fredrik....@gtempaccount.com on 20 Apr 2011 at 1:00

GoogleCodeExporter commented 8 years ago 
By the way, you should try the newest version of MoSync, 2.5 alpha. The bug may 
have been fixed already. Get it here: http://www.mosync.com/download

Original comment by fredrik....@gtempaccount.com on 20 Apr 2011 at 1:11

GoogleCodeExporter commented 8 years ago 
The same issue applies on the 2.5 alpha.

Original comment by anders.d.olofsson@gmail.com on 20 Apr 2011 at 1:57

GoogleCodeExporter commented 8 years ago 
Example project

Original comment by anders.d.olofsson@gmail.com on 26 Apr 2011 at 9:11

Attachments:

GoogleCodeExporter commented 8 years ago 
Thanks for the example it was exactly what I needed.  The issue appears to be 
connected to how Eclipse handles relative paths.  Naturally this should be the 
same in headless mode but appears not to be.  There is a workaround supported 
under 2.5 Alpha.  One new feature in 2.5 is "Path Variables".  I used them as 
follows in "Additional Include Paths"
%project:Issue1085Lib%
in "Additional Library Paths"
%project:Issue1085Lib%/Output/Release

We will look further into why the relative paths differ in Eclipse.

Original comment by miles.mi...@gtempaccount.com on 26 Apr 2011 at 12:36

GoogleCodeExporter commented 8 years ago 
Path variables do solve the issue. Thanks! :)

...but it does not solve the very same issue that appears when trying to code 
sign (for Android). The absolute path to the keystore is 
"C:\issue1085\Issue1085Moblet\android.keystore". The keystore path set in the 
MoSync project is relative ("../../../android.keystore"), though.

jarsigner error: java.lang.RuntimeException: keystore load: 
C:\issue1085\Issue1085Moblet\FinalOutput\android.keystore (The system cannot 
find the file specified)

If I set the keystore path to "%project:%Issue1085Moblet/android.keystore" and 
try to build in the IDE, I get the following error message:

jarsigner error: java.lang.RuntimeException: keystore load: The filename, 
directory name, or volume label syntax is incorrect

Original comment by anders.d.olofsson@gmail.com on 26 Apr 2011 at 2:15

GoogleCodeExporter commented 8 years ago 
I noticed another thing. There's no mosyncc equivalence on Mac OS! A mosync.exe 
exists, though, but cannot be executed for obvious reasons.

Original comment by anders.d.olofsson@gmail.com on 28 Apr 2011 at 2:35

GoogleCodeExporter commented 8 years ago 
Same with mosync 2.7

Building: Project DHHelloNativeUI for profile HTC/Desire HD
Configuration: Debug

d:\MoSync\bin\pipe-tool.exe -appcode=HDJE -stabs=stabs.tab -heapsize=2097152 
-datasize=4194304 -sld=sld.tab -sd:\MoSync\lib\pipe -B 
D:\MoSync\workspace\DHHelloNativeUI\Output\Debug\program 
D:\MoSync\workspace\DHHelloNativeUI\Output\Debug\main.s 
D:\MoSync\workspace\DHHelloNativeUI\Output\Debug\Test.s 
D:\MoSync\workspace\DHHelloNativeUI\Output\Debug\sqlite3.s 
D:\MoSync\workspace\DHHelloNativeUI\Output\Debug\Settings.s 
D:\MoSync\workspace\DHHelloNativeUI\Output\Debug\Home.s 
D:\MoSync\workspace\DHHelloNativeUI\Output\Debug\DefaultUI.s 
D:\MoSync\workspace\DHHelloNativeUI\Output\Debug\JSONParser.s mastdD.lib 
MAUtilD.lib NativeUI.lib newlib.lib
failed to load 'newlib.lib'

Original comment by david.ch...@gmail.com on 2 Nov 2011 at 1:18

GoogleCodeExporter commented 8 years ago 
Could you please supply more information.  This original issue was relating to 
project dependencies however your problem looks like there is a problem with 
libraries.  From the command line you supplied it appears that you are 
including newlib.lib and mastdD.lib which is not supported (you may only use 
one or the other).  I suspect the reason it failed to load newlib.lib is there 
is no additional library path set.  If you support more information I will be 
happy to try and assist.

Original comment by miles.mi...@mobilesorcery.com on 2 Nov 2011 at 1:44

GoogleCodeExporter commented 8 years ago 
Hello everyone.. I am trying to do push notification with the CBHelper.lib but 
I cannot load this library and I am getting an error pipe tool failed...Here is 
my log. Please Help!

--> GCC PIPIL Compiler v2:16:58:48:Dec  7 2010 (O2)
Time for buildstep Compile: 406ms.
Performing build step 'Link'
/Applications/MoSync/bin/pipe-tool -appcode=XDEQ -stabs=stabs.tab 
-heapsize=3145728 -stacksize=524288 -datasize=4194304 -sld=sld.tab 
-s/Volumes/Amma/STUDIES/Mosync/CBHelper/Output/Release -B 
/Volumes/Amma/STUDIES/Mosync/Amma/Output/Release/Android/Android/program 
/Volumes/Amma/STUDIES/Mosync/Amma/Output/Release/Android/Android/main.s 
CBHelper.lib NativeUI.lib Wormhole.lib Notification.lib
failed to load 'CBHelper.lib'
Pipe tool failed. (See console for more information).
 Command line: /Applications/MoSync/bin/pipe-tool -appcode=XDEQ -stabs=stabs.tab -heapsize=3145728 -stacksize=524288 -datasize=4194304 -sld=sld.tab -s/Volumes/Amma/STUDIES/Mosync/CBHelper/Output/Release -B /Volumes/Amma/STUDIES/Mosync/Amma/Output/Release/Android/Android/program /Volumes/Amma/STUDIES/Mosync/Amma/Output/Release/Android/Android/main.s CBHelper.lib NativeUI.lib Wormhole.lib Notification.lib

Original comment by haribruc...@gmail.com on 31 Oct 2014 at 8:08