I'm trying to install the zip library.
wonko:Desktop andrew$ alisp
International Allegro CL Free Express Edition
8.2 [Mac OS X (Intel)] (Jan 25, 2010 14:49)
Copyright (C) 1985-2010, Franz Inc., Oakland, CA, USA. All Rights Reserved.
This development copy of Allegro CL is licensed to:
Allegro CL 8.2 Express user
;; Optimization settings: safety 1, space 1, speed 1, debug 2.
;; For a complete description of all compiler switches given the
;; current optimization settings evaluate (EXPLAIN-COMPILER-SETTINGS).
CL-USER(1): (asdf:oos 'asdf:load-op :zip)
; Autoloading for package "ASDF":
; Fast loading /Applications/AllegroCL/code/ASDF.fasl
; Autoloading for package "EXCL.OSI":
; Fast loading /Applications/AllegroCL/code/OSI.fasl
; Fast loading from bundle code/fileutil.fasl.
; Autoloading for package "REGEXP":
; Fast loading from bundle code/regexp2-s.fasl.
; Autoloading for REGEXP::MAKE-VM-CLOSURE:
; Fast loading /Applications/AllegroCL/code/regexp2.fasl
; Fast loading /Applications/AllegroCL/code/YACC.fasl
Error: component "zip" not found
[condition type: MISSING-COMPONENT]
Restart actions (select using :continue):
0: Return to Top Level (an "abort" restart).
1: Abort entirely from this (lisp) process.
[1] CL-USER(2):
Specs:
Allegro CL 8.2
ASDF (presumably included with Allegro)
Mac OS X 10.6.4
MacBook Pro 5,1
The weird thing is that ASDF doesn't appear to search online for zip. It just gives up.
ASDF does not download libraries, you have to get them yourself. ASDF only searches the directories that are in the list asdf:central-registry for system definition files (.asd). If you want automatic installation and downloading of libraries checkout quicklisp or clbuild
Related
I am in the process of creating a pure x64 version of my application. In order to do that, I also need an x64 installer. I've read online that the NSIS code does support x64 but since they don't distribute an x64 build that I need to build from source (including all plugins/etc).
I've been able to build NSIS (v3.0.4) from source for x86 using Python 2.7/SCons 3.1.1/VS 2012/Zlib 1.2.7.
scons ZLIB_W32=C:\Source\zlib-1.2.7
But when I add the TARGET_ARCH=amd64 to the scons command,
scons ZLIB_W32=C:\Source\zlib-1.2.7 TARGET_ARCH=amd64
It doesn't work. Initially it built but didn't link because zlib was still x86.
C:\Source\zlib-1.2.7\lib\zdll.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
However, after rebuilding zlib1.dll (using VS2012) to be x64 (dumpbin confirms this)
I now get an error that it can't find zlib
scons ZLIB_W32=C:\Source\zlib-1.2.7 TARGET_ARCH=amd64
scons: Reading SConscript files ...
WARNING: VER_PACKED not set, defaulting to 0x03003666!
Delete("nsis-18-Nov-2019.cvs")
Delete(".instdist")
Delete(".test")
Using Microsoft tools configuration (14.2)
Checking for memset requirement... (cached) yes
Checking for memcpy requirement... (cached) yes
Checking for C library gdi32... (cached) yes
Checking for C library user32... (cached) yes
Checking for C library pthread... (cached) no
Checking for C library iconv... (cached) no
Checking for C library shlwapi... (cached) yes
Checking for C library oleaut32... (cached) yes
Checking for C library version... (cached) yes
Checking for C library zdll... no
Checking for C library z... no
zlib (win32) is missing!
Note that I have made sure that the directory structure matches in the x64 build so that the following files exist:
C:\Source\zlib-1.2.7\zlib1.dll
C:\Source\zlib-1.2.7\lib\zlib1.lib
C:\Source\zlib-1.2.7\include\zconf.h
C:\Source\zlib-1.2.7\include\zlib.h
It did occur to me that I'm telling scons to look for x86 zlib (hence the W32 in ZLIB_W32) but I didn't see an option for telling scons to look for x64 zlib in the -h output.
What am I missing?
-UPDATE 1-
I'm making progress but not out of the woods yet. I've identified several issues with my build. #1, I wasn't actually using VS2012 like I thought (I have several versions installed). See above where the scons output says 14.0 (VS2019). Oops. Unfortunately, simply adding a MSVC_VERSION=11.0 to my command line didn't fix it. It seems that the nsis project isn't passing this along to scons. The only way I could figure out how to do this was to modify the nsis SConstruct file from:
######################################################################
####### Build Environment ###
######################################################################
path = ARGUMENTS.get('PATH', '')
toolset = ARGUMENTS.get('TOOLSET', '')
arch = ARGUMENTS.get('TARGET_ARCH', 'x86')
if toolset and path:
defenv = Environment(TARGET_ARCH = arch, ENV = {'PATH' : path}, TOOLS = toolset.split(',') + ['zip'])
else:
if path:
defenv = Environment(TARGET_ARCH = arch, ENV = {'PATH' : path})
if toolset:
defenv = Environment(TARGET_ARCH = arch, TOOLS = toolset.split(',') + ['zip'])
if not toolset and not path:
defenv = Environment(TARGET_ARCH = arch)
Export('defenv')
to:
######################################################################
####### Build Environment ###
######################################################################
path = ARGUMENTS.get('PATH', '')
toolset = ARGUMENTS.get('TOOLSET', '')
arch = ARGUMENTS.get('TARGET_ARCH', 'x86')
vs_version = ARGUMENTS.get('MSVC_VERSION', '')
if toolset and path:
defenv = Environment(TARGET_ARCH = arch, ENV = {'PATH' : path}, TOOLS = toolset.split(',') + ['zip'], MSVC_VERSION = vs_version)
else:
if path:
defenv = Environment(TARGET_ARCH = arch, ENV = {'PATH' : path}, MSVC_VERSION = vs_version)
if toolset:
defenv = Environment(TARGET_ARCH = arch, TOOLS = toolset.split(',') + ['zip'], MSVC_VERSION = vs_version)
if not toolset and not path:
defenv = Environment(TARGET_ARCH = arch, MSVC_VERSION = vs_version)
Export('defenv')
Now my build output correctly identifies as VS2012:
C:\Source\nsis\nsis-code-r7069-NSIS-tags-v304>scons ZLIB_W32=C:\Source\zlib MSVC_VERSION=11.0
scons: Reading SConscript files ...
WARNING: VER_PACKED not set, defaulting to 0x03003666!
Delete("nsis-19-Nov-2019.cvs")
Delete(".instdist")
Delete(".test")
Using Microsoft tools configuration (11.0)
Checking for memset requirement... (cached) yes
<snip>
It seems like there should be a better way to allow this but I'm not familiar enough (yet) with scons or nsis's usage of it to submit a PR to fix this. Or maybe it already exists and I'm just not smart enough to find it (yet).
Now, on to building x64 nsis. Big thanks to #Anders for narrowing down which files are needed a bit and #bdbaddog for suggesting to look into the scons config.log where I found that I had named the zlib.dll lib file incorrectly when I build it for x64. After changing the output lib to
C:\Source\zlib-1.2.7\lib\zdll.lib
It at least tries to build but fails at linking...
-edit to update 1- all of the linking errors that were here previously were a bad rabbit hole I went down yesterday. Not sure if it was caused by scons leaving some temp files somewhere or VS doing it or me just being stupid but today when I started trying to track down the linking errors I couldn't reproduce them (there was a machine reboot yesterday and who knows what might have been locked/cached until then).
-UPDATE 2-
This update is removing all the mis-leading crap from update 1. Current situation is x64 NSIS build (using both my zlib-1.2.7-amd64 build AND the official NSIS zlib-1.2.8-amd64 pre-built binaries on the NSIS wiki) is failing at linking with the same error:
System.obj : error LNK2019: unresolved external symbol CallProc2 referenced in function Call
build\urelease\System\amd64-unicode\System.dll : fatal error LNK1120: 1 unresolved externals
scons: *** [build\urelease\System\amd64-unicode\System.dll] Error 1120
scons: building terminated because of errors.
So far I'm not having any luck figuring out what CallProc2 is but I think this means zlib is no longer at fault here.
-UPDATE 3-
Thanks to #Anders for the direction here since I was really stumped on the Callproc issue, the CallProc2 method is isolated to the system plugin and is caused by it not building correctly. There is some discussion in the comments below trying to find the cause but for now, I'm just excluding that plugin to get to a system that works before coming back to this.
Right now, the scons build completes and produces x64 binaries.
C:\Source\nsis\build\urelease\makensisw\>dumpbin /HEADERS ./makensisw.exe
Microsoft (R) COFF/PE Dumper Version 11.00.61030.0
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file ./makensisw.exe
PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
8664 machine (x64)
However, the installer build now results in the following error:
scons dist-installer ZLIB_W32=C:\Source\zlib-1.2.8-x64 MSVC_VERSION=11.0
link /nologo /map /subsystem:console,5.01 /OUT:build\urelease\VPatch\Source\GenPat\GenPat.exe /LIBPATH:C:\Source\zlib-1.2.8-x64\lib zdll.lib build\urelease\VPatch\Source\GenPat\adler32.obj build\urelease\VPatch\Source\GenPat\Checksums.obj build\urelease\VPatch\Source\GenPat\ChunkedFile.obj build\urelease\VPatch\Source\GenPat\FileFormat1.obj build\urelease\VPatch\Source\GenPat\GlobalTypes.obj build\urelease\VPatch\Source\GenPat\main.obj build\urelease\VPatch\Source\GenPat\md5.obj build\urelease\VPatch\Source\GenPat\PatchGenerator.obj build\urelease\VPatch\Source\GenPat\POSIXUtil.obj
adler32.obj : error LNK2019: unresolved external symbol _adler32 referenced in function "unsigned long __cdecl Checksum::adler32(unsigned long,unsigned char const *,unsigned int)" (?adler32#Checksum##YAKKPBEI#Z)
build\urelease\VPatch\Source\GenPat\GenPat.exe : fatal error LNK1120: 1 unresolved externals
scons: *** [build\urelease\VPatch\Source\GenPat\GenPat.exe] Error 1120
Unfortunately, without the installer, I'm kinda lost again. The x64 binaries run but when trying to compile any script (I believe), I get the following error (note that I copied makensis and zlib1.dll into the same directory for this):
C:\Source>makensis.exe ./myapp.nsi
Error: reading stub "C:\Stubs\zlib-amd64-unicode"
Error initalizing CEXEBuild: error setting default stub
-UPDATE 4-
I have finally gotten a build to work successfully after ignoring the system plugin. This works both with compiling zlib from source for x64 or with the prebuilt version from the NSIS wiki (linked in #Anders answer below):
scons ZLIB_W32=C:\Source\zlib-1.2.8-x64 TARGET_ARCH=amd64 MSVC_VERSION=11.0 SKIPPLUGINS=System
and I was able to deploy to my dev system using (from an admin enabled prompt since I was installing to Program Files):
scons PREFIX="C:\Program Files (x86)\NSIS" install ZLIB_W32=C:\Source\zlib-1.2.8-x64 TARGET_ARCH=amd64 SKIPPLUGINS=System
Unfortunately, you cannot build the NSIS installer from here (dist-install) because the NSIS installer itself apparently depends on usage of the System plugin. So this scenario isn't sufficient for being able to prep a build machine unless you are going to build everything from scratch on that machine.
Also, I'm not out of the woods yet because I also use the System plugin for my installer so I need to figure out why that isn't working.
However, I was able to compile and run a pure x64 bare minimum installer package with the above setup:
# name the installer
OutFile "Installer.exe"
# default section start; every NSIS script has at least one section.
Section
# default section end
SectionEnd
The above was straight out of the NSIS docs.
My environment:
cl.exe:
Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28316 for x64
nsis version: 3.06.1
zlib: Zlib-1.2.8-win64-AMD64
I modified SCons/Tool/masm.py:
C:\miniconda3\Lib\site-packages\SCons-4.0.1-py3.7.egg\SCons\Tool>diff -c masm.old.py masm.py
*** masm.old.py Fri Oct 09 22:02:45 2020
--- masm.py Fri Oct 09 21:58:06 2020
***************
*** 61,66 ****
--- 61,68 ----
shared_obj.add_emitter(suffix, SCons.Defaults.SharedObjectEmitter)
env['AS'] = 'ml'
+ if env.get('TARGET_ARCH')=='amd64':
+ env['AS'] = 'ml64'
env['ASFLAGS'] = SCons.Util.CLVar('/nologo')
env['ASPPFLAGS'] = '$ASFLAGS'
env['ASCOM'] = '$AS $ASFLAGS /c /Fo$TARGET $SOURCES'
Also modified nsis-3.06.1-src\Contrib\System\SConscript as follows:
C:\dev\nsis-3.06.1-src\Contrib\System>diff -c SConscript.old SConscript
*** SConscript.old Fri Oct 09 22:06:31 2020
--- SConscript Fri Oct 09 19:17:40 2020
***************
*** 4,9 ****
--- 4,10 ----
Source/Buffers.c
Source/Plugin.c
Source/System.c
+ Source/Call-amd64.S
""")
libs = Split("""
Then C:\dev\nsis-3.06.1-src>scons TARGET_ARCH=amd64 ended successfully.
I have
\zlib1.dll
\include\zconf.h
\include\zlib.h
\lib\libzdll.a
\lib\zdll.lib
\lib\zlib.lib
You can get pre-built zlib for NSIS here.
In the past I have actually used Process Monitor to figure out which file SCons is looking for, that sadly seems to be the fastest way to find out.
Regarding CallProc2. Add "System" to SKIPPLUGINS to get past this issue to make sure everything else compiles. CallProc2 is implemented in the amd64 .S file and used by system.c. You need the 64-bit Microsoft assembler detected correctly to build the .S file.
If you only need to compile NSIS once then you can cheat; Open a Visual Studio command prompt and execute ml64.exe /c Call-amd64.S and then copy the .obj file to the same build directory as system.obj and run Scons again.
To do it properly you need to investigate why Scons is not compiling the .S file. Could be a configuration issue or a bug in the related Sconscript file.
I'm building Skia on Windows following this link.
For Windows x64 the build was quite smooth. But not for 32 bit.
1) I tried specifying target_cpu = "x86" instead of target_cpu = "x64", gn gen works fine but ninja throws errors complaining that the paths to visual studio contain spaces. It has all sorts of errors similar to the following:
"C:\Programs " is not a valid path.
2) I tried generating sln files and building from within IDE (which is an alternative as mentioned in the link). However, I can't even get the x64 version to compile this way (a lot of non-zero exit codes from ninja, no further messages observed).
3) I tried using the toolchain that the website claims to be "the only way to support 32 bit builds". The toolchain is to be downloaded using the following command (to be executed in skia dir):
python infra/bots/assets/win_toolchain/download.py -t C:/toolchain
I managed to work around loads of intricacies (gutil conflicts, .py extension omissions, path variables, to google cloud service) and I'm now stuck at this:
Logged in as xxxxxxxxxxxxxxxx
AccessDeniedException: 403 Caller does not have storage.objects.list access to bucket skia-buildbots.
I'm not restricted to the way it is built so long as it generates the "libs" for me. But with a large project having so many external dependencies I don't think it's easy to brew my own way.
One solution I've found:
Open the out\Release\toolchain.ninja text file (or the toolchain.ninja specific to your configuration)
Remove the following string (you can use a "Replace Text" with an empty string in your text editor):
C:/Program Files (x86)/Microsoft Visual Studio 14.0/win_sdk/bin/SetEnv.cmd /x86 && C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64_x86/
from everywhere (in case that you've used the x86, for x64 the string might be different)
And use ninja -C out/Release dm as usual
In this way we are using a toolchain where cl.exe, ml.exe link.exe commands are called directly (accesible from the PATH environment)
An other solution base on #dacap's. But I edit the gn configure instead.
Change file gn/toolchain/BUILD.gn
...
if (msvc == 2015) {
bin = "$win_vc/bin/amd64"
} else {
bin = "$win_vc/Tools/MSVC/$win_toolchain_version/bin/HostX64/$target_cpu"
}
env_setup = ""
if (target_cpu == "x86") {
# Toolchain asset includes a script that configures for x86 building.
# We don't support x86 builds with local MSVC installations.
env_setup = "cmd /c $win_sdk/bin/SetEnv.cmd /x86 && "
}
...
To
...
if (msvc == 2015) {
if (target_cpu == "x86") {
bin = "$win_vc/bin"
} else {
bin = "$win_vc/bin/amd64"
}
} else {
bin = "$win_vc/Tools/MSVC/$win_toolchain_version/bin/HostX64/$target_cpu"
}
env_setup = ""
#if (target_cpu == "x86") {
# # Toolchain asset includes a script that configures for x86 building.
# # We don't support x86 builds with local MSVC installations.
# env_setup = "cmd /c $win_sdk/bin/SetEnv.cmd /x86 && "
#}
.....
It seems that (as of skia m67) #WinCloud's fix is partially merged to upstream (still has to remove env_setup part though).
However, as noted in comments - it will crash during OpenGL initialization.
I've fixed all that (at least to the point where demo apps are runnable), as a little extra - fixed .lib compatibility with Visual Studio's Debug configurations.
Included are .bat files that build "no system libs" configuration with Clang (as the readme explicitly states that VC++ builds may have performance issues). To use those just download latest LLVM from https://releases.llvm.org/download.html and install it into default location (tested with 6.0.0).
If you need DLL runtime linking you'll have to edit gn/BUILD.gn file - add /MD flag by default and change /MTd to /MDd for debug.
Here's patch based on chrome/m67 branch:
https://gist.github.com/Alexx999/39eae9182eecaa3dc06e73fdb3a1e7d9
I have bought a ARM7S processor and I wanted to deploy the NETMF there. So I installed the .NETMF porting kit and a CodeSourcery GCC 4.6.3 compiler and tried to compile the solution for my processor.
I should say I have Windows 8.1 Enterprise x64, Visual Studio 2013 Ultimate installed on my PC.
At first I set debugger using this command: "setenv.cmd 4.6.3 C:\gcc" where I had installed my CodeSourcery ARM-EABI gcc compiler.
After that I had moved to folder "Solutions/--my CPU --/TinyCLR" and ran this command: "MSBUILD.EXE /t:build /p:flavor=release;memory=flash"
It took some time and throw a huge amount of errors. I downloaded a older version of the compiler and only one error left.
So I opened a clear version of Windows 7 x86 (virtually) and installed Visual Studio 2012 Professional. After that I tried the same but the error was the same.
"c:\MicroFrameworkPK_v4_3\Solutions\SAM7S_EK\TinyCLR\TinyCLR.proj" (build targe
t) (1) ->
(BuildAXF target) ->
c:\MicroFrameworkPK_v4_3\tools\targets\Microsoft.SPOT.System.GCC.targets(325,
5): error MSB3073: The command ""C:\gcc\bin\..\arm-none-eabi\bin\ld.exe" -stat
ic --gc-sections --no-warn-mismatch --library-path=c:\MicroFrameworkPK_v4_3\Bui
ldOutput\THUMB\GCC4.2\le\FLASH\release\SAM7S_EK\lib --library-path=c:\MicroFram
eworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\ANY_MEDIA\release\lib --allow-multip
le-definition -u ARM_Vectors -u _start --Map c:\MicroFrameworkPK_v4_3\BuildOutp
ut\THUMB\GCC4.2\le\FLASH\release\SAM7S_EK\bin\tinyclr.map --output=c:\MicroFram
eworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\FLASH\release\SAM7S_EK\bin\tinyclr.axf
--script=c:\MicroFrameworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\FLASH\release\SA
M7S_EK\bin\tinyclr_scatterfile.ldf c:\MicroFrameworkPK_v4_3\BuildOutput\THUMB\G
CC4.2\le\FLASH\release\SAM7S_EK\obj\Solutions\SAM7S_EK\TinyCLR\tinyclr_dat.obj
c:\MicroFrameworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\FLASH\release\SAM7S_EK\obj
\Solutions\SAM7S_EK\TinyCLR\allocator.obj c:\MicroFrameworkPK_v4_3\BuildOutput\
THUMB\GCC4.2\le\FLASH\release\SAM7S_EK\obj\Solutions\SAM7S_EK\TinyCLR\tinyclr.o
bj -( c:\MicroFrameworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\ANY_MEDIA\release\li
b\Core.lib c:\MicroFrameworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\ANY_MEDIA\relea
se\lib\Hardware.lib c:\MicroFrameworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\ANY_ME
DIA\release\lib\InterruptHandler.lib c:\MicroFrameworkPK_v4_3\BuildOutput\THUMB
\GCC4.2\le\ANY_MEDIA\release\lib\HeapPersistence_stub.lib c:\MicroFrameworkPK_v
4_3\BuildOutput\THUMB\GCC4.2\le\ANY_MEDIA\release\lib\I2C_stub.lib c:\MicroFram
eworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\ANY_MEDIA\release\lib\IOPort.lib c:\Mi
croFrameworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\ANY_MEDIA\release\lib\RPC_stub.
lib c:\MicroFrameworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\ANY_MEDIA\release\lib\
Serialization_stub.lib c:\MicroFrameworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\ANY
_MEDIA\release\lib\Debugger.lib c:\MicroFrameworkPK_v4_3\BuildOutput\THUMB\GCC4
.2\le\ANY_MEDIA\release\lib\Debugger_full.lib c:\MicroFrameworkPK_v4_3\BuildOut
put\THUMB\GCC4.2\le\ANY_MEDIA\release\lib\Diagnostics_stub.lib c:\MicroFramewor
kPK_v4_3\BuildOutput\THUMB\GCC4.2\le\ANY_MEDIA\release\lib\Graphics_stub.lib c:
\MicroFrameworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\ANY_MEDIA\release\lib\CorLib
.lib c:\MicroFrameworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\ANY_MEDIA\release\lib
\SPOT.lib c:\MicroFrameworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\ANY_MEDIA\releas
e\lib\SPOT_Messaging_stub.lib c:\MicroFrameworkPK_v4_3\BuildOutput\THUMB\GCC4.2
\le\ANY_MEDIA\release\lib\SPOT_Serialization_stub.lib c:\MicroFrameworkPK_v4_3\
BuildOutput\THUMB\GCC4.2\le\ANY_MEDIA\release\lib\SPOT_Hardware.lib c:\MicroFra
meworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\ANY_MEDIA\release\lib\Messaging.lib c
:\MicroFrameworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\ANY_MEDIA\release\lib\CLRSt
artup.lib c:\MicroFrameworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\ANY_MEDIA\releas
e\lib\CRC.lib c:\MicroFrameworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\ANY_MEDIA\re
lease\lib\WireProtocol.lib c:\MicroFrameworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le
\ANY_MEDIA\release\lib\SPOT_Hardware_SerialPort.lib c:\MicroFrameworkPK_v4_3\Bu
ildOutput\THUMB\GCC4.2\le\FLASH\release\SAM7S_EK\lib\tmp_tinyclr.lib c:\MicroFr
ameworkPK_v4_3\BuildOutput\THUMB\GCC4.2\le\FLASH\release\SAM7S_EK\lib\InteropAs
sembliesTable.lib -) -( "C:\gcc\arm-none-eabi\lib\thumb\libm.a" "C:\gcc\arm-non
e-eabi\lib\thumb\libc.a" "C:\gcc\lib\gcc\arm-none-eabi\4.2.1\thumb\libgcc.a" -)
-( c:\MicroFrameworkPK_v4_3\tools\ads_v3_1\Lib\armlib\h_t.l c:\MicroFrameworkP
K_v4_3\tools\ads_v3_1\Lib\armlib\c_t.l -)" exited with code 1. [c:\MicroFramewo
rkPK_v4_3\Solutions\SAM7S_EK\TinyCLR\TinyCLR.proj]
Does anybody knows how to fix it or if there is a place, where I can find compiler CLR?
Thanks,
Jonas
I have compiled and run my Matlab code sucessfully in my computer, but there is something wrong when I run it on annother. The error information as following:
bash-3.1# sh /data/release/cli/forecaster_new/forecaster/run_dispatch.sh /usr/local/matlab /data/release/cli/forecaster_new/forecaster/1-1.txt /data/release/cli/forecaster_new/forecaster/1-1.out
------------------------------------------
Setting up environment variables
---
LD_LIBRARY_PATH is .:/usr/local/matlab/runtime/glnxa64:/usr/local/matlab/bin/glnxa64:/usr/local/matlab/sys/os/glnxa64:/usr/local/matlab/sys/java/jre/glnxa64/jre/lib/amd64/native_threads:/usr/local/matlab/sys/java/jre/glnxa64/jre/lib/amd64/server:/usr/local/matlab/sys/java/jre/glnxa64/jre/lib/amd64/client:/usr/local/matlab/sys/java/jre/glnxa64/jre/lib/amd64
Warning: This functionality is no longer supported under the -nojvm startup
option. For more information, see "Changes to -nojvm Startup Option" in the
MATLAB Release Notes. To view the release note in your system browser, run
web('http://www.mathworks.com/access/helpdesk/help/techdoc/rn/bropbi9-1.html#brubkzc-1',
'-browser')
> In run_predict at 5
??? Invalid MEX-file
'/usr/local/matlab/toolbox/compiler/mcr/compiler/deploywhich.mexa64':
/usr/local/matlab/runtime/glnxa64/libmwopczippackage.so: undefined symbol:
_ZN2fl10filesystem6detail19process_code_traits11to_internalERKSs.
Error in ==> fopen at 16
Error in ==> dlmwrite at 120
Error in ==> run_predict at 71
MATLAB:invalidMEXFile
Warning: 1 invisible figure(s) exist at MCR termination.
If your application has terminated unexpectedly, please note that
applications generated by the MATLAB Compiler terminate when there are no
visible figure windows. See the documentation for WaitForFiguresToDie and
WAITFORCALLBACKS for more information.
The OS of the compiling computer is Ubuntu 7.10(64-bits)， the Matlab version is Matlab r2010a, and the gcc version is 4.1.3.
I am using ghc 7.6.3. I installed wxHaskell from here: https://github.com/wxHaskell/wxHaskell
It worked, the sample programs compile and the run successfully.
The only problem now is that I want to distribute a wxHaskell application on mac OS X. I tried using macosx-app and cabal-macosx (https://github.com/michaelt/cabal-macosx) to make an "app" file. It runs fine on my machine, but it fails to run on another computer. I get the following error:
Dyld Error Message: Library not loaded: /Users/user/.cabal/lib/wxc-0.90.1.0/ghc-7.6.3/libwxc.dylib.
I am using OS X 10.8.4 (Mountain Lion), but I would be also interested in compiling apps on Windows and redistribute them too.
What would be the best way to redistribute wxHaskell apps?
Setup.hs
-- Example Setup.hs for the wxHello app.
import Distribution.MacOSX
import Distribution.Simple
main :: IO ()
main = defaultMainWithHooks $ simpleUserHooks {
postBuild = appBundleBuildHook guiApps -- no-op if not MacOS X
}
guiApps :: [MacApp]
guiApps = [MacApp "WxHello"
(Just "resources/WxHello.icns")
Nothing -- Build a default Info.plist for the icon.
[] -- No other resources.
[] -- No other binaries.
ChaseWithDefaults -- Try changing to ChaseWithDefaults
]
wxHello.cabal:
Name: wxHello
Version: 0.1.0
Stability: Alpha
Synopsis: wxWidgets `Hello World' example for cabal-macosx
Description:
Example showing how to use cabal-macosx to build an application
bundle for a simple `Hello World' program using the wxWidgets GUI
toolkit.
Category: Data
License: BSD3
License-file: LICENSE
Copyright: Andy Gimblett <haskell#gimbo.org.uk>
Author: Andy Gimblett <haskell#gimbo.org.uk>
Maintainer: Andy Gimblett <haskell#gimbo.org.uk>
Build-Type: Custom
Cabal-Version: >=1.6
Executable WxHello
hs-source-dirs: src
Main-is: Main.hs
Build-Depends: base >= 3 && < 5, cabal-macosx, wx
ghc-options: -fwarn-tabs -threaded -Wall
Here are the dylib files inside the generated package:
WxHello.app $ find . | grep dylib
./Contents/Frameworks/Users/user/.cabal/lib/wxc-0.90.1.0/ghc-7.6.3/libwxc.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_baseu-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_baseu_net-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_baseu_xml-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_adv-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_aui-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_core-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_gl-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_html-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_propgrid-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_qa-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_ribbon-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_richtext-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_stc-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_webview-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_xrc-2.9.5.0.0.dylib
./Contents/Frameworks/usr/lib/libc++abi.dylib
./Contents/Frameworks/usr/lib/libexpat.1.dylib
./Contents/Frameworks/usr/lib/libiconv.2.dylib
./Contents/Frameworks/usr/lib/libstdc++.6.dylib
./Contents/Frameworks/usr/lib/libz.1.dylib
The last redistributable I made in Windows with wxHaskell needed the files
mingwm10.dll and
wxmws28u_gcc.dll
to be in the same folder as the .exe (not just somewhere on my path).
This was using a previous version of wxHaskell, which compiled against a previous version of wxWidgits itself, so presumably you'd need the wx dll to have 29 in it rather than 28.
I compiled with static linking too:
ghc -static -optl-static -optl-mwindows Main -o Project.exe
the -optl-mwindows gets rid of the command prompt window which would otherwise appear alongside your app.
It might be helpful to include your .cabal and Setup.hs files.
From the documentation on cabal-macosx, it seems that you need to ensure that your MacApp data value in Setup.hs gets the appropriate mode for ChaseDeps (use ChaseWithDefaults instead of DoNotChase) in order to build redistributable app bundles.
If you have done that but still get the same error, I would check inside the resulting app bundle to see if the necessary libraries got copied in there at all. You may find enough information to file a bug with the cabal-macosx maintainer.
Edit
Based on what you've included, the setup looks correct, and it appears to have at least copied the library dependencies in. I think the problem is probably with the cabal-macosx package.
Looking at the source code to the dependency-fixup code, it looks like it should have printed a bunch of "Updating <library>'s dependence on <path> to <path>" lines as it was building the bundle. Did you see those? Were there any lines updating the binary itself?
I am not very experienced with the OS X linking process, but I would think that unless the binary is linked after copying the libraries, it would need to be updated as well. You should be able to use /usr/bin/otool -L <filename> and /usr/bin/install_name_tool to manually fix up the paths in binaries the install process may have missed.
Here are the man pages for those two tools:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/install_name_tool.1.html
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/otool.1.html