I have simple SFML Network code of chat:
https://github.com/4EFI/Online-Chat/blob/main/Online%20Chat/OnlineChat.cpp
But it don't compile in Visual Studio. For graphics apps I set next project parameters:
C/C++ -> Preprocessor -> Defines of preprocessor -> SFML_DYNAMIC
Linker -> Input -> ... ->
sfml-graphics-d.lib
sfml-window-d.lib
sfml-system-d.lib
sfml-audio-d.lib
(for Debug)
and
sfml-graphics.lib
sfml-window.lib
sfml-system.lib
sfml-audio.lib
(for Release).
What I must to do to SFML Network can to compile?
I want to write a simple Internet-Chat with SFML Network.
I can to find the solve:
Linker -> Input ->
sfml-network.lib
sfml-network-d.lib
Related
I have sqlite3 installed in Ubuntu.
$ which sqlite3
/home/user/anaconda3/bin/sqlite3
I'm trying to install the sqlite driver in Haskell and see the following error:
$ stack install sqlite
sqlite-0.5.5: configure
sqlite-0.5.5: build
-- While building custom Setup.hs for package sqlite-0.5.5 using:
/tmp/stack16820/sqlite-0.5.5/.stack-work/dist/x86_64-linux/Cabal-2.2.0.1/setup/setup --builddir=.stack-work/dist/x86_64-linux/Cabal-2.2.0.1 build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
Process exited with code: ExitFailure 1
Logs have been written to: /home/user/.stack/global-project/.stack-work/logs/sqlite-0.5.5.log
[1 of 2] Compiling Main ( /tmp/stack16820/sqlite-0.5.5/Setup.hs, /tmp/stack16820/sqlite-0.5.5/.stack-work/dist/x86_64-linux/Cabal-2.2.0.1/setup/Main.o )
[2 of 2] Compiling StackSetupShim ( /home/user/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /tmp/stack16820/sqlite-0.5.5/.stack-work/dist/x86_64-linux/Cabal-2.2.0.1/setup/StackSetupShim.o )
Linking /tmp/stack16820/sqlite-0.5.5/.stack-work/dist/x86_64-linux/Cabal-2.2.0.1/setup/setup ...
Configuring sqlite-0.5.5...
Preprocessing library for sqlite-0.5.5..
Building library for sqlite-0.5.5..
[1 of 5] Compiling Database.SQL.Types ( Database/SQL/Types.hs, .stack-work/dist/x86_64-linux/Cabal-2.2.0.1/build/Database/SQL/Types.o )
/tmp/stack16820/sqlite-0.5.5/Database/SQL/Types.hs:481:37: error:
Ambiguous occurrence ‘<>’
It could refer to either ‘Prelude.<>’,
imported from ‘Prelude’ at Database/SQL/Types.hs:15:8-25
(and originally defined in ‘GHC.Base’)
or ‘Text.PrettyPrint.HughesPJ.<>’,
imported from ‘Text.PrettyPrint.HughesPJ’ at Database/SQL/Types.hs:56:1-32
|
481 | FunSQLExpr f es -> text f <> parens (commaH ppSQLExpr es)
| ^^
Which of ghc, stack, cabal, anaconda, sqlite should I interrogate to figure out what is failing?
I'm trying to install the sqlite driver in Haskell and see the following error
The sqlite package is deprecated in favour of sqlite-simple So, I would recommend you to not use this. If you are looking for a much higher level of interface to sqlite, I would recommend persistent library.
If you want to still make it work, the easiest way is to just fix the compile errors by forking the code and make it work with the required GHC version.
TL;DR
stack install sqlite --resolver=lts-11.22 should work
First of all i would follow sibi advise and install the maintaned package sqlite-simple.
But if you want to use the deprecated one we could analyze the error:
The error is thrown in the haskell part, the combination of stack and haskell. No mention about c code so the sqlite lib (or anaconda) is not involved here
Ambiguous occurrence ‘<>’ It could refer to either ‘Prelude.<>’, or ‘Text.PrettyPrint.HughesPJ.<>’: The simbol <> is defined in two modules and the client code doesn't disambiguate them (surely cause it was only in one module at the time)
So we have to compile with a version of Prelude or Text.PrettyPrint.HughesPJ without the definition of <>
Text.PrettyPrint.HughesPJ is a module from the pretty package and all versions of the package have the operator exported
The Prelude is defined in the base library and it is fixed for each version of ghc, that in turn is fixed for each major version of the stackage resolver. You can set the global stack resolver in ~/stack/global-project/stack.yaml or in each call to stack with the option --resolver=
The package sqlite accepts base versions in the range >=3 && <5 (in fact that is the cause of the problem, it is too flexible)
If we search for <> in the changelog of base we can see it was exported since version 4.11.0. And that version was shipped with ghc-8.4.1 (you can see the matrix between versions here). So we have to choose a stackage resolver linked to a previous version of ghc: f.e. lts-11.22 with ghc-8.2.2
I've created a proof of concept blazor website on a VSTS repository. I wanted to setup a pipeline to build and test it but I've some issues.
In my visual studio, I've no troubles to build my solution, either by rebuilding the whole solution on Visual studio, either by running dotnet build my-sln.sln.
On VSTS, when I come to my build step, I've this issue:
2018-10-10T13:32:19.9132557Z ##[section]Starting: Build
2018-10-10T13:32:19.9137589Z ==============================================================================
2018-10-10T13:32:19.9137671Z Task : .NET Core
2018-10-10T13:32:19.9137712Z Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command. For package commands, supports NuGet.org and authenticated feeds like Package Management and MyGet.
2018-10-10T13:32:19.9137754Z Version : 2.141.0
2018-10-10T13:32:19.9137806Z Author : Microsoft Corporation
2018-10-10T13:32:19.9137844Z Help : [More Information](https://go.microsoft.com/fwlink/?linkid=832194)
2018-10-10T13:32:19.9137901Z ==============================================================================
2018-10-10T13:32:20.7843899Z [command]C:\Windows\system32\chcp.com 65001
2018-10-10T13:32:20.9185978Z Active code page: 65001
2018-10-10T13:32:20.9791878Z [command]"C:\Program Files\dotnet\dotnet.exe" build D:\a\1\s\T-Dash.sln --configuration release
2018-10-10T13:32:27.3327317Z
2018-10-10T13:32:27.3330859Z Welcome to .NET Core!
2018-10-10T13:32:27.3331044Z ---------------------
2018-10-10T13:32:27.3331238Z Learn more about .NET Core # https://aka.ms/dotnet-docs. Use dotnet --help to see available commands or go to https://aka.ms/dotnet-cli-docs.
2018-10-10T13:32:27.3331363Z Telemetry
2018-10-10T13:32:27.3331657Z --------------
2018-10-10T13:32:27.3331810Z The .NET Core tools collect usage data in order to improve your experience. The data is anonymous and does not include commandline arguments. The data is collected by Microsoft and shared with the community.
2018-10-10T13:32:27.3332525Z You can opt out of telemetry by setting a DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your favorite shell.
2018-10-10T13:32:27.3332584Z You can read more about .NET Core tools telemetry # https://aka.ms/dotnet-cli-telemetry.
2018-10-10T13:32:27.3332627Z Configuring...
2018-10-10T13:32:27.3332685Z -------------------
2018-10-10T13:32:27.3332740Z A command is running to initially populate your local package cache, to improve restore speed and enable offline access. This command will take up to a minute to complete and will only happen once.
2018-10-10T13:32:32.3411921Z Decompressing 0%Decompressing 1%Decompressing 2%Decompressing 3%Decompressing 4%Decompressing 5%Decompressing 6%Decompressing 7%Decompressing 8%Decompressing 9%Decompressing 10%Decompressing 11%Decompressing 12%Decompressing 13%Decompressing 14%Decompressing 15%Decompressing 16%Decompressing 17%Decompressing 18%Decompressing 19%Decompressing 20%Decompressing 21%Decompressing 22%Decompressing 23%Decompressing 24%Decompressing 25%Decompressing 26%Decompressing 27%Decompressing 28%Decompressing 29%Decompressing 30%Decompressing 31%Decompressing 32%Decompressing 33%Decompressing 34%Decompressing 35%Decompressing 36%Decompressing 37%Decompressing 38%Decompressing 39%Decompressing 40%Decompressing 41%Decompressing 42%Decompressing 43%Decompressing 44%Decompressing 45%Decompressing 46%Decompressing 47%Decompressing 48%Decompressing 49%Decompressing 50%Decompressing 51%Decompressing 52%Decompressing 53%Decompressing 54%Decompressing 55%Decompressing 56%Decompressing 57%Decompressing 58%Decompressing 59%Decompressing 60%Decompressing 61%Decompressing 62%Decompressing 63%Decompressing 64%Decompressing 65%Decompressing 66%Decompressing 67%Decompressing 68%Decompressing 69%Decompressing 70%Decompressing 71%Decompressing 72%Decompressing 73%Decompressing 74%Decompressing 75%Decompressing 76%Decompressing 77%Decompressing 78%Decompressing 79%Decompressing 80%Decompressing 81%Decompressing 82%Decompressing 83%Decompressing 84%Decompressing 85%Decompressing 86%Decompressing 87%Decompressing 88%Decompressing 89%Decompressing 90%Decompressing 91%Decompressing 92%Decompressing 93%Decompressing 94%Decompressing 95%Decompressing 96%Decompressing 97%Decompressing 98%Decompressing 99%Decompressing 100% 4694 ms
2018-10-10T13:33:07.6280747Z Expanding 0%Expanding 1%Expanding 2%Expanding 3%Expanding 4%Expanding 5%Expanding 6%Expanding 7%Expanding 8%Expanding 9%Expanding 10%Expanding 11%Expanding 12%Expanding 13%Expanding 14%Expanding 15%Expanding 16%Expanding 17%Expanding 18%Expanding 19%Expanding 20%Expanding 21%Expanding 22%Expanding 23%Expanding 24%Expanding 25%Expanding 26%Expanding 27%Expanding 28%Expanding 29%Expanding 30%Expanding 31%Expanding 32%Expanding 33%Expanding 34%Expanding 35%Expanding 36%Expanding 37%Expanding 38%Expanding 39%Expanding 40%Expanding 41%Expanding 42%Expanding 43%Expanding 44%Expanding 45%Expanding 46%Expanding 47%Expanding 48%Expanding 49%Expanding 50%Expanding 51%Expanding 52%Expanding 53%Expanding 54%Expanding 55%Expanding 56%Expanding 57%Expanding 58%Expanding 59%Expanding 60%Expanding 61%Expanding 62%Expanding 63%Expanding 64%Expanding 65%Expanding 66%Expanding 67%Expanding 68%Expanding 69%Expanding 70%Expanding 71%Expanding 72%Expanding 73%Expanding 74%Expanding 75%Expanding 76%Expanding 77%Expanding 78%Expanding 79%Expanding 80%Expanding 81%Expanding 82%Expanding 83%Expanding 84%Expanding 85%Expanding 86%Expanding 87%Expanding 88%Expanding 89%Expanding 90%Expanding 91%Expanding 92%Expanding 93%Expanding 94%Expanding 95%Expanding 96%Expanding 97%Expanding 98%Expanding 99%Expanding 100% 34027 ms
2018-10-10T13:33:41.4866462Z Object reference not set to an instance of an object.
2018-10-10T13:33:41.6079659Z ##[error]Error: C:\Program Files\dotnet\dotnet.exe failed with return code: 1
2018-10-10T13:33:41.6090166Z ##[error]Dotnet command failed with non-zero exit code on the following projects : D:\a\1\s\T-Dash.sln
2018-10-10T13:33:41.6128848Z ##[section]Finishing: Build
I don't really see what could be wrong here? Any idea?
While trying to load the RProvider.fsx, I get a error that the Assembly reference RDotNet.dll was not found or is invalid
I'm following this walktrough: http://bluemountaincapital.github.io/FSharpRProvider/Statistics-QuickStart.html
Using Visual Studio 15 (I use the free community edition)
Create new F# console project: UseNuGetPackage (Exact steps NOT given)
Download and install R (Exact steps NOT given)
Install R Type provider
In Visual Studio using Solution Explorer
Right click F# project e.g. UseNuGetPackage
Select: Manage NuGet Packages for Solution
Click Browse
Enter: RProvider
Click check box on the left of Project
Click Install
Click OK
The Visual Studio output window shows:
Attempting to gather dependencies information for package 'RProvider.1.1.15' with respect to project 'UseNuGetPackage', targeting '.NETFramework,Version=v4.5.2'
Attempting to resolve dependencies for package 'RProvider.1.1.15' with DependencyBehavior 'Lowest'
Resolving actions to install package 'RProvider.1.1.15'
Resolved actions to install package 'RProvider.1.1.15'
Adding package 'DynamicInterop.0.7.4' to folder 'c:\users\eric\documents\visual studio 2015\Projects\UseNuGetPackage\packages'
Added package 'DynamicInterop.0.7.4' to folder 'c:\users\eric\documents\visual studio 2015\Projects\UseNuGetPackage\packages'
Added package 'DynamicInterop.0.7.4' to 'packages.config'
Successfully installed 'DynamicInterop 0.7.4' to UseNuGetPackage
Adding package 'R.NET.Community.1.6.4' to folder 'c:\users\eric\documents\visual studio 2015\Projects\UseNuGetPackage\packages'
Added package 'R.NET.Community.1.6.4' to folder 'c:\users\eric\documents\visual studio 2015\Projects\UseNuGetPackage\packages'
Added package 'R.NET.Community.1.6.4' to 'packages.config'
Successfully installed 'R.NET.Community 1.6.4' to UseNuGetPackage
Adding package 'R.NET.Community.FSharp.1.6.4' to folder 'c:\users\eric\documents\visual studio 2015\Projects\UseNuGetPackage\packages'
Added package 'R.NET.Community.FSharp.1.6.4' to folder 'c:\users\eric\documents\visual studio 2015\Projects\UseNuGetPackage\packages'
Added package 'R.NET.Community.FSharp.1.6.4' to 'packages.config'
Successfully installed 'R.NET.Community.FSharp 1.6.4' to UseNuGetPackage
Adding package 'RProvider.1.1.15' to folder 'c:\users\eric\documents\visual studio 2015\Projects\UseNuGetPackage\packages'
Added package 'RProvider.1.1.15' to folder 'c:\users\eric\documents\visual studio 2015\Projects\UseNuGetPackage\packages'
Added package 'RProvider.1.1.15' to 'packages.config'
Successfully installed 'RProvider 1.1.15' to UseNuGetPackage
========== Finished ==========
Notice in the image below the green check mark identifying that the package is installed.
Notice in the image below the new references for the project.
To get the following two statements to work we need to verify some paths.
#I "../packages/RProvider.1.0.11"
#load "RProvider.fsx"
The example given is specific to a version and as we know versions change so check the version of the DLL that will be used.
In the F# project
Right click the RProvider reference
Right click Properties
Here is the full path so you don't have to squint
c:\users\eric\documents\visual studio 2015\Projects\UseNuGetPackage\packages\RProvider.1.1.15\lib\net40\RProvider.dll
The example is using version RProvider.1.0.11 and we have RProvider.1.1.15
so we need to update the line from the example to
#I "../packages/RProvider.1.1.15"
If you look a lot of examples where you download a package from NuGet and then use it with F# Interactive you will see the same pattern to get it started.
#I "../packages/<Name_XYZ>.<Version>"
#load "<Name_XYZ>.fsx"
This is because this code assumes that you have used NuGet to install the needed DLLs in a VS project and that the DLLS are in a packages directory that is relative to the source code for the project. If you look back at the listing I gave for the output window you will see the copying of the DLLs.
Here they are shown in File Explorer
So how does F# Interactive know how to find the DLLs when it only has a relative path.
Now for the magical missing part that we leave out because it is a
conspiracy to test newbies. :-)
F# Interactive has the property __SOURCE_DIRECTORY__ that gives the location of the source directory in a VS project. This can be seen in F# Interactive with
printfn __SOURCE_DIRECTORY__
which for my example is
c:\users\eric\documents\visual studio 2015\Projects\UseNuGetPackage\UseNuGetPackage
val it : unit = ()
if you get a directory containing AppData then restart F# Interactive.
This can be checked with File Explorer
sure enough this is the source directory for the project.
More importantly the path from the source directory to the NuGet packages is
../packages
So all the paths look good.
Now that we have updated and checked the script lines to load the DLL give it a try.
We get the error:
error FS0082: Could not resolve this reference. Could not locate the assembly "RDotNet.FSharp.dll".
The problem is the specific versions mentioned in RProvider.fsx
// Standard NuGet locations for R.NET
#I "../R.NET.Community.1.5.16/lib/net40"
#I "../R.NET.Community.FSharp.0.1.9/lib/net40"
If we substitute out #load "RProvider.fsx" with
#r "../packages/R.NET.Community.1.6.4/lib/net40/RDotNet.dll"
#r "../packages/R.NET.Community.FSharp.1.6.4/lib/net40/RDotNet.FSharp.dll"
#r "../packages/RProvider.1.1.15/lib/net40/RProvider.dll"
#r "../packages/RProvider.1.1.15/lib/net40/RProvider.Runtime.dll"
open RProvider
do fsi.AddPrinter(fun (synexpr:RDotNet.SymbolicExpression) -> synexpr.Print())
open System
open RDotNet
open RProvider
open RProvider.graphics
open RProvider.stats
The example works. e.g.
// Random number generator
let rng = Random()
let rand () = rng.NextDouble()
// Generate fake X1 and X2
let X1s = [ for i in 0 .. 9 -> 10. * rand () ]
let X2s = [ for i in 0 .. 9 -> 5. * rand () ]
// Build Ys, following the "true" model
let Ys = [ for i in 0 .. 9 -> 5. + 3. * X1s.[i] - 2. * X2s.[i] + rand () ]
let dataset =
namedParams [
"Y", box Ys;
"X1", box X1s;
"X2", box X2s; ]
|> R.data_frame
let result = R.lm(formula = "Y~X1+X2", data = dataset)
let coefficients = result.AsList().["coefficients"].AsNumeric()
let residuals = result.AsList().["residuals"].AsNumeric()
let summary = R.summary(result)
summary.AsList().["r.squared"].AsNumeric()
R.plot result
Also as Tomas noted in his answer there is a bug with the version numbers in the fsx file, but he was able to update the source code and make a new alpha version.
:)
Hopefully I gave enough detail that the next time you see one of these examples on using a NuGet package with F# Interactive and have a problem you can resolve it.
There is a bug in RProvider.fsx where it references a wrong version of R.NET. The version 1.1.16-alpha has a fix for this, but we did not release a new non-beta yet.
Can you check that this works fine if you install 1.1.16-alpha?
The link of #GuyCoder helped me: How does F# Interactive #I command know about project path?
I searched the missing .dll files on my computer, and pasted in the parent folder of the source directory.
After this everything worked fine
#I "../packages/RProvider.1.1.15"
(*
#r "RDotNet.dll"
#r "RDotNet.FSharp.dll"
These 2 are unnecessary*)
#load "RProvider.fsx"
open System
open RDotNet
open RProvider
open RProvider.graphics
open RProvider.stats
EDIT:
I first downloaded the nuget packages Rdotnet & Rdotnet.Fsharp, then I searched on my computer for the dll's,
Then I copied these files and pasted it in the directory I was working in:
Which you also can find with __SOURCE_DIRECTORY__
I am am unable to get avr-elf-windows and WinAVR to work. I have managed to build the example supplied with avr-elf-windows (ATmega2560). But if I try and expand to use another chip or start using the WinAVR supplied packages and projects I keep getting errors I cannot work out.
Method 1:
Modify the ATmega2560 example to use the WinAVR packages.
Changed:
with Atmega2560; use Atmega2560;
to:
with AVR; use AVR;
with AVR.Atmega328p; use AVR.atmega328p;
Create a project file to include:
with "C:\WinAVR-20100110\lib\gnat\avr.gpr";
with "C:\WinAVR-20100110\lib\gnat\avr_app.gpr";
Running make I get the following error:
avr-gnatmake: "C:\WinAVR-20100110\lib\gnat\avr_lib\avr-int_img.adb" compilation error
Great, I have a compilation issue, but I cannot see the error.
Method 2:
Open the above project file in GPS. Change the build setting to be gnatmake. GPS now starts reporting errors and warnings:
Project warning: object directory "avr_lib/avr5/obj" not found
Project library directory "C:\WinAVR-20100110\lib\gnat\avr_lib\avr5\lib\" does not exist
The latter issue is very clearly the fact that I have not set up GPS correctly to tell it the values of microcontroller and architecture, but I cannot seem to find anything to resolve this.
Method 3:
To use the WinAVR set up directly using makefiles which then gives me the error:
avr-gnatmake: RTS path not valid: missing adainclude and adalib directories
If I follow the instructions I can find by searching the web I can only find details for building the required libraries under Linux.
Platform: Windows 7.
With the combination of the two answers above I have now managed to link my sample code. As to wether it will work on the Arduino, that is a different issue.
Many thanks for the help.
I have found it a bit frustrating to get this far, and I wonder if there are others out there who may just give up on Ada on the Arduino and go back to the Arduino IDE and therefore missing out on the opportunity to learn a language with more structure. There are many misleading pages out there that also do not help.
You might want to take a look in the paper Integrating 8-bit AVR Micro-Controllers in Ada. Basically you can use a GPS project file arduino.gpr like
project Arduino is
for Source_Dirs use (".", "src");
for Object_Dir use "obj";
for Exec_Dir use "bin";
for Main use ("main.adb");
package Compiler is
for Default_Switches ("ada") use ("-mmcu=avr5");
end Compiler;
package Ide is
for Gnat use "avr-gnat";
for Gnatlist use "avr-gnatls";
for Debugger_Command use "avr-gdb";
end Ide;
package Builder is
for Executable_Suffix use ".elf";
for Default_Switches ("ada") use ("--RTS=rts-zfp");
end Builder;
package Linker is
for Default_Switches ("ada") use ("obj\crtm328p._o", "-nostdlib", "-lgcc", "-mavr5", "-Tdata=0x00800200", "-mmcu=avr5");
end Linker;
end Arduino;
and you can code a spec for your ATmega328P like
with Interfaces; use Interfaces;
with System;
package ATmega328P is
-- PORTB: Port B Data Register
PORTB : Unsigned_8;
for PORTB'Address use System'To_Address (16#25#);
-- DDRB: Port B Data Direction Register
DDRB : Unsigned_8;
for DDRB'Address use System'To_Address (16#24#);
-- PINB: Port B Input Pins
PINB : Unsigned_8;
for PINB'Address use System'To_Address (16#23#);
end ATmega328P;
to be imported by your main file or libraries.
Bear with me if this isn't the immediate answer; I have only used the AVR-Ada toolchain on Linux, so we may have to iterate towards a solution unless someone else spots the problem first.
The first thing to decipher is which version of the AVR-Ada tools you have:
your project file USED to need (using avr-ada 1.1)
with "C:\WinAVR-20100110\lib\gnat\avr.gpr";
Now with avr-ada 1.2.1 you need (instead)
with "C:\WinAVR-20100110\lib\gnat\avr_app.gpr";
for building applications, and <same path>/avr_lib.gpr for libraries.
I don't believe you ever need both! And they may conflict with each other.
I don't know the state of the Windows binary build, but if you need the latest version (recommended : it's a real improvement) you may need to build it from source.
Method 1 : were you running Make from a command line? If so, I would expect to see errors in all their gory details.
Method 2 : can't help you here, I don't know GPS well enough. However I can say that on Linux there are no "avr5" folders in [wherever]/avr/lib/gnat/avr_lib. (AVR5 is correct for the 328p)
Instead there IS a [wherever]/avr/lib/avr5 containing libc and other C-related objects - including the crtm328p.o that Rego names in his linker switches, and a [wherever]/lib/gcc/avr/4.7.2/avr5 folder containing libgcc.a. You probably need to find the former and point GPS at it...
Method 3 : This looks the easiest to fix. The "gnatmake" command needs an --RTS= option pointing at the correct RTS for the 328p. This should be --RTS=rts/avr5 assuming the RTS is correctly installed.
Alternatively a full path ought to work. Here, that would be
--RTS=/opt/avr_472_gnat/lib/gcc/avr/4.7.2/rts/avr5
on Windows you may have to poke around to find the correct path.
Using Method 1 this --RTS option is automatically generated by avr_app.gpr.
It appears that having a mix of 3 or 4 tool chains installed that provide one of aspects of WinAvr, AvrAda causes significant problems (these included WinAvr, Avr-Ada, Cygwin, AVR compiler by Adacore and MinWG).
Starting with a brand new Win7 or Win8 installation perform the following:
Install WinAVR-20100110 to C:\WinAVR-20100110
Copy the content of the Avr-Ada-1.2.0_bin to C:\avr-ada-1.2.0
Add C:\avr-ada-1.2.0\bin to the PATH
Compiling the content of each of the examples in C:\avr-ada-1.2.0\share\doc\avr-ada\apps identifies that some DLLs are missing: libiconv-2.dll, libgmp-10.dll, libmpc-2.dll, libmpfr-1.dll
These can be found in a MinGW installtion.
Create a virtual machine to install MinGW on, in order to ensure it did not mess with the main PC.
Copy the missing DLLs in C:\WinAVR-20100110\bin
The example in DS1820 will not compile due to crc_lib being missing.
In order to upload to the Arduino the makefiles must be modified for your local installation, board type etc.
I have an Xcode 3.2 project (sqlite3 with icu) that builds correctly, and I'm trying to recreate it in Xcode 4. I'm getting link errors:
Undefined symbols for architecture x86_64:
"vtable for __cxxabiv1::__si_class_type_info", referenced from:
typeinfo for icu_48::SortKeyByteSinkin libicui18n.a(ucol.ao)
...
"___gxx_personality_v0", referenced from:
Dwarf Exception Unwind Info (__eh_frame) in libicui18n.a(uregex.ao)
...
I had this once before, with Xcode 3.2. I it then by changing build setting Linking-> C++ Standard Library Type to static (the default is dynamic). If I understand the docs correctly, the actual flag is STANDARD_C_PLUS_PLUS_LIBRARY_TYPE.
But I can't find that setting in Xcode 4!
EDIT
The main module (sqlite3) is C, but the ICU library is C++, presumably with C declarations. I can build sqlite3 fine by itself, it's when I need to link in the ICU library that the trouble starts.
Your app may be C but it looks like libicui18n includes C++.
What happens if you rename your main.m to main.mm? That should cause it to be linked against the standard C++ library.