Re: [Mono-dev] Problem with Odbc on 64 bit identified, please advise action
On Tue, 2008-03-18 at 23:26 +0100, Mads Bondo Dydensborg wrote:
> Hi there
>
> In libodbc.cs, imports are on this form:
>
> [DllImport("odbc32.dll")]
> internal static extern OdbcReturn SQLGetData (
> IntPtr StatementHandle,
> ushort ColumnNumber,
> SQL_C_TYPE TargetType,
> ref OdbcTimestamp TargetPtr,
> int BufferLen,
> ref int Len);
>
> BufferLen and Len are ints. However, on 64 bit odbc (tested with Debian
> 4.0/AMD using Sybase 9.0.2), they need to be long/64 bit. This works, whereas
> the above does not:
>
> [DllImport("odbc32.dll")]
> internal static extern OdbcReturn SQLGetData (
> IntPtr StatementHandle,
> ushort ColumnNumber,
> SQL_C_TYPE TargetType,
> ref OdbcTimestamp TargetPtr,
> System.Int64 BufferLen,
> ref System.Int64 Len);
>
> There are problem also other places, besides SQLGetData
>
> So, what to do? Should I just file a bug, or any suggestions on a patch? I
> have no idea about Odbc per se, I just needed this to work. :-/
So here's the real problem: SQLGetData() et al use the SQLLEN type,
which in the publicly available unixODBC-2.2.12 is:
#if (SIZEOF_LONG == 8)
#ifndef BUILD_REAL_64_BIT_MODE
typedef int SQLINTEGER;
typedef unsigned intSQLUINTEGER;
#define SQLLEN SQLINTEGER
i.e. SQLLEN is 32-bit by default, while CVS-HEAD has:
#if (SIZEOF_LONG_INT == 8)
#ifdef BUILD_LEGACY_64_BIT_MODE
typedef int SQLINTEGER;
typedef unsigned intSQLUINTEGER;
#define SQLLEN SQLINTEGER
// ...
#else
typedef int SQLINTEGER;
typedef unsigned intSQLUINTEGER;
typedef longSQLLEN;
i.e. SQLLEN is 64bit by default. You can't reconcile these differences
-- they BROKE the ABI!
So, what do most distros use? If everyone has migrated to CVS-HEAD,
then we should use `IntPtr' instead of `int' (as IntPtr will be 32-bit
on 32-bit platforms and 64-bit on 64-bit platforms). Otherwise, we
should probably stick with `int'.
It doesn't even look like it's possible to do a runtime version check,
as I don't see any versioning function within unixODBC (except perhaps
for TraceVersion(), but the .tar.gz download doesn't actually implement
that so I can't compare). A version check wouldn't help anyway, as it's
apparently still possible to use the "alternate" ABI by providing a
preprocessor define.
In short, we can "fix" this for you, but in the process we may end up
breaking some other platform. There is no good solution.
- Jon
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem with Odbc on 64 bit identified, please advise action
There's a slight issue with that unfortunately. If you're on Windows64, and
int is still an int32. If you're on nix64, an int is an int64. So, if you
*only* care about linux support, then the change you outlined is perfect,
however if you want to retain Win64 support, you can't do that.
There are two ways to enable support for both 64bit platforms.
1) Write 2 sets of p/invokes and detect at runtime which one you should
call. One exposes an int32, the other an int64.
2) Write a glue library in C which you p/invoke. This native library will
expose an int64 in it's public api (the one you p/invoke) and then the glue
library will call into the regular odbc32.dll library.
Which is suitable, i can't say. Someone else would have to decide that.
Alan.
On Tue, Mar 18, 2008 at 10:26 PM, Mads Bondo Dydensborg <[EMAIL PROTECTED]>
wrote:
> Hi there
>
> In libodbc.cs, imports are on this form:
>
>[DllImport("odbc32.dll")]
>internal static extern OdbcReturn SQLGetData (
>IntPtr StatementHandle,
>ushort ColumnNumber,
>SQL_C_TYPE TargetType,
>ref OdbcTimestamp TargetPtr,
>int BufferLen,
>ref int Len);
>
> BufferLen and Len are ints. However, on 64 bit odbc (tested with Debian
> 4.0/AMD using Sybase 9.0.2), they need to be long/64 bit. This works,
> whereas
> the above does not:
>
>[DllImport("odbc32.dll")]
>internal static extern OdbcReturn SQLGetData (
>IntPtr StatementHandle,
>ushort ColumnNumber,
>SQL_C_TYPE TargetType,
>ref OdbcTimestamp TargetPtr,
>System.Int64 BufferLen,
>ref System.Int64 Len);
>
> There are problem also other places, besides SQLGetData
>
> So, what to do? Should I just file a bug, or any suggestions on a patch? I
> have no idea about Odbc per se, I just needed this to work. :-/
>
> Regards
>
> Mads
>
> --
> Med venlig hilsen/Regards
>
> Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo
> Dydensborg
> Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86
> 77 34
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Problem with Odbc on 64 bit identified, please advise action
Hi there
In libodbc.cs, imports are on this form:
[DllImport("odbc32.dll")]
internal static extern OdbcReturn SQLGetData (
IntPtr StatementHandle,
ushort ColumnNumber,
SQL_C_TYPE TargetType,
ref OdbcTimestamp TargetPtr,
int BufferLen,
ref int Len);
BufferLen and Len are ints. However, on 64 bit odbc (tested with Debian
4.0/AMD using Sybase 9.0.2), they need to be long/64 bit. This works, whereas
the above does not:
[DllImport("odbc32.dll")]
internal static extern OdbcReturn SQLGetData (
IntPtr StatementHandle,
ushort ColumnNumber,
SQL_C_TYPE TargetType,
ref OdbcTimestamp TargetPtr,
System.Int64 BufferLen,
ref System.Int64 Len);
There are problem also other places, besides SQLGetData
So, what to do? Should I just file a bug, or any suggestions on a patch? I
have no idea about Odbc per se, I just needed this to work. :-/
Regards
Mads
--
Med venlig hilsen/Regards
Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg
Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] GIT# project for GSOC
Hi all, I would like to work in the GIT# project for the Mono organization for the GSOC, yesterday that I saw the project it caught my attention. I headed on the GIT IRC channel to see prior art and Shawn Pearce(spearce at #git in freenode) told me(besides there's not an managed implementation outside of jgit) that there was a GIT# project in Mono last year, well I want to know what's up with that? I Googled it and only found an old application and not even in Mono's lists. Regards. -- http://igordevlog.blogspot.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Maemo OS2008 / Scratchbox
I am trying to compile mono so I can install it on my N800 running OS2008 but haven't had much luck. I followed the recipe at http://www.mono-project.com/Scratchbox but don't know what to do after the last step. After following it I was able to run "make maemo/debs" and that was about it. How do I get it to compile all the libraries and where can I find the files that I need to copy to my device? Thanks in advance, Felipe ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problems cross compiling Mono itself for ARM with uClibc
Hi, > > > > I think the problem is located in the message: "configure: error: C > compiler cannot create executables". > > > > I don't know what to do. I really need help! > > > > Thomas This is configuration problem and has little to do with mono. You can try looking into the config.log file produced by configure to see what it tries to do and what fails. Zoltan > > > > > Hi Thomas, > > > > > > > Hello, > > > > > > > > is it possible, that the configuration step of Mono tries to execute > > > > a file on my i386 architecture platform, compiled with the arm-gcc? > > > > > > In general that's possible with configure scripts, but here it's > > > trying to execute `arm-linux-gcc --version`, see below. I'd assume > > > you'll get a similar error message if you execute it yourself from a > > > terminal? If so, then your cross-compiler setup is broken. > > > > > > > If this is the reason, how can I solve the problem? Is there a > > > > configuration-switch or a workaround which I've overlooked? > > > > > > Once you get to the point where you encounter such a situation you can > > > provide a cache file with the relevant settings (it can be useful to > > > make the file read-only while testing or it'll be overwritten). > > > > > > Andreas > > > > > > > > > > Greets, Thomas > > > > > > > > Original-Nachricht > > > >> Datum: Thu, 13 Mar 2008 22:09:01 +0100 > > > >> Von: "Andreas Färber" <[EMAIL PROTECTED]> > > > >> An: [EMAIL PROTECTED] > > > >> CC: mono-devel-list@lists.ximian.com > > > >> Betreff: Re: [Mono-dev] Problems cross compiling Mono itself for > > > >> ARM with uClibc > > > > > > > >> > > > >> Am 13.03.2008 um 21:53 schrieb [EMAIL PROTECTED]: > > > >> > > > >>> Hello, > > > >>> > > > >>> I'm trying to cross compile the mono package 1.2.6 with my arm- > > > >>> linux- > > > >>> gcc-4.1.2 shipped with my development board synertronixx scb9520 > > > >>> with a preinstalled Linux RT 2.6.18 Kernel. I'm unsuccessfully > > > >>> trying this job for 1 month. > > > >>> > > > >>> My host platform is a Fedora 8 i386 machine. I copied the cross > > > >>> compiler suite to /usr/local and set the environment variables, as > > > >>> you can see below: > > > >>> > > > >>> # env | grep PATH > > > >>> PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib/ccache:/usr/ > > > >>> local/ > > > >>> sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/ > > > >>> gcc-4.1.2-uClibc-0.9.29-xscale/bin:/root/bin > > > >>> > > > >>> Then I unpacked the mono package to /usr/local and then I tried to > > > >>> configure it with the following command: > > > >>> CC=arm-linux-gcc ./configure --prefix=/urs --target=arm-linux -- > > > >>> with- > > > >>> glib=embedded --with-gc=boehm --with-static_mono=yes --disable-mcs- > > > >>> build --enable-static > > > >>> > > > >>> All what I get as output are the following lines: > > > >>> [EMAIL PROTECTED] mono-1.2.6]# CC=arm-linux-gcc ./configure --prefix=/ > > > >>> urs --target=arm-linux --with-glib=embedded --with-gc=boehm --with- > > > >>> static_mono=yes --disable-mcs-build --enable-static > > > >>> checking build system type... i686-pc-linux-gnu > > > >>> checking host system type... i686-pc-linux-gnu > > > >>> checking target system type... arm-unknown-linux-gnu > > > >>> checking for a BSD-compatible install... /usr/bin/install -c > > > >>> checking whether build environment is sane... yes > > > >>> checking for a thread-safe mkdir -p... /bin/mkdir -p > > > >>> checking for gawk... gawk > > > >>> checking whether make sets $(MAKE)... yes > > > >>> checking how to create a ustar tar archive... gnutar > > > >>> checking whether to enable maintainer-specific portions of > > > >>> Makefiles... no > > > >>> checking whether ln -s works... yes > > > >>> ./configure: line 2844: ./libtool: No such file or directory > > > >>> checking host platform characteristics... ok > > > >>> checking for gcc... arm-linux-gcc > > > >>> checking for gcc... (cached) arm-linux-gcc > > > >>> checking for C compiler default output file name... > > > >>> configure: error: C compiler cannot create executables > > > >>> See `config.log' for more details. > > > >>> > > > >>> Here is the config.log: > > > >>> === > > > >>> > > > >> > > > >>> configure:3491: checking for C compiler version > > > >>> configure:3498: arm-linux-gcc --version >&5 > > > >>> ./configure: line 3499: /usr/local/gcc-4.1.2-uClibc-0.9.29-xscale/ > > > >>> bin/arm-linux-gcc: cannot execute binary file > > > >>> configure:3501: $? = 126 > > > >> > > > >> That's apparently a problem with your compiler, not with Mono > > > >> configuration. > > > >> > > > >> Andreas > > > > > > > > -- > > > > Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free > > > > Games! > > > > http://games.entertainment.gmx.net/de/entertainment/games/free > > > > ___ > > > > Mono-devel-list mailing list > > > > Mono-devel-list@lists.ximian.com > > > > http://lists
Re: [Mono-dev] Commercial support
On Mon, Mar 17, 2008 at 11:33 PM, E Robertson <[EMAIL PROTECTED]> wrote: > Novell is listed as the only commercial support available. Is their > any other not mentioned? I know some people who might be able to help commercially. Please contact me directly if you would like to discuss. Otherwise, if you post your questions in more detail to the list, I'm sure someone will be able to answer. Have fun, Avery ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problems cross compiling Mono itself for ARM with uClibc
It has been a few months since I have used an ARM tool-chain, but I do recall that we had issues with various 'configure' (autoconf) tests. When running configure we also received "C compiler cannot create executables" - after I dove into it - I found that the gcc options where not right and it was not outputing the right executable name. So it wasn't able to find it I thought this might help. Tim On 3/18/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hello, > > I've tested my gcc with a sample program (a kind of "hello world"), but it > works fine. It compiles the source and I get a executable file, which I can > run on my ARM-Platform. > > What I've done (as user:root, in the directory /usr/local/mono-1.2.6): > # export CC=arm-linux-gcc (it is available in my env - see previous > posting) > # ./configure --with-glib=embedded (because I'd like to use the uClibs) > > I also tried to configure and make mono 1.2.6 with the compiler for my > native architecture (i386) - it works fine too. > > I think the problem is located in the message: "configure: error: C > compiler cannot create executables". > > I don't know what to do. I really need help! > > Thomas > > > Hi Thomas, > > > > > Hello, > > > > > > is it possible, that the configuration step of Mono tries to execute > > > a file on my i386 architecture platform, compiled with the arm-gcc? > > > > In general that's possible with configure scripts, but here it's > > trying to execute `arm-linux-gcc --version`, see below. I'd assume > > you'll get a similar error message if you execute it yourself from a > > terminal? If so, then your cross-compiler setup is broken. > > > > > If this is the reason, how can I solve the problem? Is there a > > > configuration-switch or a workaround which I've overlooked? > > > > Once you get to the point where you encounter such a situation you can > > provide a cache file with the relevant settings (it can be useful to > > make the file read-only while testing or it'll be overwritten). > > > > Andreas > > > > > > > Greets, Thomas > > > > > > Original-Nachricht > > >> Datum: Thu, 13 Mar 2008 22:09:01 +0100 > > >> Von: "Andreas Färber" <[EMAIL PROTECTED]> > > >> An: [EMAIL PROTECTED] > > >> CC: mono-devel-list@lists.ximian.com > > >> Betreff: Re: [Mono-dev] Problems cross compiling Mono itself for > > >> ARM with uClibc > > > > > >> > > >> Am 13.03.2008 um 21:53 schrieb [EMAIL PROTECTED]: > > >> > > >>> Hello, > > >>> > > >>> I'm trying to cross compile the mono package 1.2.6 with my arm- > > >>> linux- > > >>> gcc-4.1.2 shipped with my development board synertronixx scb9520 > > >>> with a preinstalled Linux RT 2.6.18 Kernel. I'm unsuccessfully > > >>> trying this job for 1 month. > > >>> > > >>> My host platform is a Fedora 8 i386 machine. I copied the cross > > >>> compiler suite to /usr/local and set the environment variables, as > > >>> you can see below: > > >>> > > >>> # env | grep PATH > > >>> PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib/ccache:/usr/ > > >>> local/ > > >>> sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/ > > >>> gcc-4.1.2-uClibc-0.9.29-xscale/bin:/root/bin > > >>> > > >>> Then I unpacked the mono package to /usr/local and then I tried to > > >>> configure it with the following command: > > >>> CC=arm-linux-gcc ./configure --prefix=/urs --target=arm-linux -- > > >>> with- > > >>> glib=embedded --with-gc=boehm --with-static_mono=yes --disable-mcs- > > >>> build --enable-static > > >>> > > >>> All what I get as output are the following lines: > > >>> [EMAIL PROTECTED] mono-1.2.6]# CC=arm-linux-gcc ./configure --prefix=/ > > >>> urs --target=arm-linux --with-glib=embedded --with-gc=boehm --with- > > >>> static_mono=yes --disable-mcs-build --enable-static > > >>> checking build system type... i686-pc-linux-gnu > > >>> checking host system type... i686-pc-linux-gnu > > >>> checking target system type... arm-unknown-linux-gnu > > >>> checking for a BSD-compatible install... /usr/bin/install -c > > >>> checking whether build environment is sane... yes > > >>> checking for a thread-safe mkdir -p... /bin/mkdir -p > > >>> checking for gawk... gawk > > >>> checking whether make sets $(MAKE)... yes > > >>> checking how to create a ustar tar archive... gnutar > > >>> checking whether to enable maintainer-specific portions of > > >>> Makefiles... no > > >>> checking whether ln -s works... yes > > >>> ./configure: line 2844: ./libtool: No such file or directory > > >>> checking host platform characteristics... ok > > >>> checking for gcc... arm-linux-gcc > > >>> checking for gcc... (cached) arm-linux-gcc > > >>> checking for C compiler default output file name... > > >>> configure: error: C compiler cannot create executables > > >>> See `config.log' for more details. > > >>> > > >>> Here is the config.log: > > >>> === > > >>> > > >> > > >>> configure:3491: checking for C compiler version > > >>> configure:3498: arm-linux-gcc --version >&5 > > >>> ./con
[Mono-dev] eglib and cygwin
Hello, I'm unable to compile eglib in a cygwin/mingw environment. I've tried the following: cd eglib ./autogen.sh cp winconfig.h config.h [modified Makefile and src/Makefile to use -mno-cygwin -g options to gcc] make I get the following errors: make[2]: Entering directory `/usr/local/src/mono/mono/eglib/src' /bin/sh ../libtool --tag=CC --mode=compile gcc -mno-cygwin -g -DHAVE_CONFIG_H -I. -I.. -I. -I/usr/local/src/mono/deps/include -Wall -D_FORTIFY_SOURCE=2 -g O0 -D_GNU_SOURCE -MT libeglib_la-gfile.lo -MD -MP -MF .deps/libeglib_la-gfile.T o -c -o libeglib_la-gfile.lo `test -f 'gfile.c' || echo './'`gfile.c gcc -mno-cygwin -g -DHAVE_CONFIG_H -I. -I.. -I. -I/usr/local/src/mono/deps/inc ude -Wall -D_FORTIFY_SOURCE=2 -g -O0 -D_GNU_SOURCE -MT libeglib_la-gfile.lo -MD -MP -MF .deps/libeglib_la-gfile.Tpo -c gfile.c -DDLL_EXPORT -DPIC -o .libs/lib glib_la-gfile.o gfile.c:40:1: warning: "S_ISREG" redefined In file included from gfile.c:34: /usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/include/sys/s tat h:72:1: warning: this is the location of the previous definition gfile.c:41:1: warning: "S_ISDIR" redefined /usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/include/sys/s tat h:68:1: warning: this is the location of the previous definition Is there a recommended way to buld eglib in a cygwin/mingw environment? Thanks in advance! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] webkit support
Am Sonntag 16 März 2008 17:28:40 schrieb Sharique uddin Ahmed Farooqui: > Hi, > Is there anyway to include webkit in my application? If you use Qt as your toolkit - the upcoming version (coming with KDE 4.1) of Qyoto (C# bindings for Qt) will have webkit support. A development version is already availible in svn. -- Arno Rehn [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problems cross compiling Mono itself for ARM with uClibc
Hello, I've tested my gcc with a sample program (a kind of "hello world"), but it works fine. It compiles the source and I get a executable file, which I can run on my ARM-Platform. What I've done (as user:root, in the directory /usr/local/mono-1.2.6): # export CC=arm-linux-gcc (it is available in my env - see previous posting) # ./configure --with-glib=embedded (because I'd like to use the uClibs) I also tried to configure and make mono 1.2.6 with the compiler for my native architecture (i386) - it works fine too. I think the problem is located in the message: "configure: error: C compiler cannot create executables". I don't know what to do. I really need help! Thomas > Hi Thomas, > > > Hello, > > > > is it possible, that the configuration step of Mono tries to execute > > a file on my i386 architecture platform, compiled with the arm-gcc? > > In general that's possible with configure scripts, but here it's > trying to execute `arm-linux-gcc --version`, see below. I'd assume > you'll get a similar error message if you execute it yourself from a > terminal? If so, then your cross-compiler setup is broken. > > > If this is the reason, how can I solve the problem? Is there a > > configuration-switch or a workaround which I've overlooked? > > Once you get to the point where you encounter such a situation you can > provide a cache file with the relevant settings (it can be useful to > make the file read-only while testing or it'll be overwritten). > > Andreas > > > > Greets, Thomas > > > > Original-Nachricht > >> Datum: Thu, 13 Mar 2008 22:09:01 +0100 > >> Von: "Andreas Färber" <[EMAIL PROTECTED]> > >> An: [EMAIL PROTECTED] > >> CC: mono-devel-list@lists.ximian.com > >> Betreff: Re: [Mono-dev] Problems cross compiling Mono itself for > >> ARM with uClibc > > > >> > >> Am 13.03.2008 um 21:53 schrieb [EMAIL PROTECTED]: > >> > >>> Hello, > >>> > >>> I'm trying to cross compile the mono package 1.2.6 with my arm- > >>> linux- > >>> gcc-4.1.2 shipped with my development board synertronixx scb9520 > >>> with a preinstalled Linux RT 2.6.18 Kernel. I'm unsuccessfully > >>> trying this job for 1 month. > >>> > >>> My host platform is a Fedora 8 i386 machine. I copied the cross > >>> compiler suite to /usr/local and set the environment variables, as > >>> you can see below: > >>> > >>> # env | grep PATH > >>> PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib/ccache:/usr/ > >>> local/ > >>> sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/ > >>> gcc-4.1.2-uClibc-0.9.29-xscale/bin:/root/bin > >>> > >>> Then I unpacked the mono package to /usr/local and then I tried to > >>> configure it with the following command: > >>> CC=arm-linux-gcc ./configure --prefix=/urs --target=arm-linux -- > >>> with- > >>> glib=embedded --with-gc=boehm --with-static_mono=yes --disable-mcs- > >>> build --enable-static > >>> > >>> All what I get as output are the following lines: > >>> [EMAIL PROTECTED] mono-1.2.6]# CC=arm-linux-gcc ./configure --prefix=/ > >>> urs --target=arm-linux --with-glib=embedded --with-gc=boehm --with- > >>> static_mono=yes --disable-mcs-build --enable-static > >>> checking build system type... i686-pc-linux-gnu > >>> checking host system type... i686-pc-linux-gnu > >>> checking target system type... arm-unknown-linux-gnu > >>> checking for a BSD-compatible install... /usr/bin/install -c > >>> checking whether build environment is sane... yes > >>> checking for a thread-safe mkdir -p... /bin/mkdir -p > >>> checking for gawk... gawk > >>> checking whether make sets $(MAKE)... yes > >>> checking how to create a ustar tar archive... gnutar > >>> checking whether to enable maintainer-specific portions of > >>> Makefiles... no > >>> checking whether ln -s works... yes > >>> ./configure: line 2844: ./libtool: No such file or directory > >>> checking host platform characteristics... ok > >>> checking for gcc... arm-linux-gcc > >>> checking for gcc... (cached) arm-linux-gcc > >>> checking for C compiler default output file name... > >>> configure: error: C compiler cannot create executables > >>> See `config.log' for more details. > >>> > >>> Here is the config.log: > >>> === > >>> > >> > >>> configure:3491: checking for C compiler version > >>> configure:3498: arm-linux-gcc --version >&5 > >>> ./configure: line 3499: /usr/local/gcc-4.1.2-uClibc-0.9.29-xscale/ > >>> bin/arm-linux-gcc: cannot execute binary file > >>> configure:3501: $? = 126 > >> > >> That's apparently a problem with your compiler, not with Mono > >> configuration. > >> > >> Andreas > > > > -- > > Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free > > Games! > > http://games.entertainment.gmx.net/de/entertainment/games/free > > ___ > > Mono-devel-list mailing list > > Mono-devel-list@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Pt! Schon vom neuen GMX MultiMessenger gehört
