compiling on amd64

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

compiling on amd64

Damyan Ivanov
Hi,

I've just tried to compile flamerobin on my home amd64 machine and it
failed :-(

Here's the output:

$ make
./bk-make-pch .pch/ibpp/ibpp.h.gch ibpp.h g++ -I.pch/ibpp -DIBPP_GCC
-DIBPP_LINUX -I../src/ibpp -I../src/ibpp/fbheaders
-I/usr/lib/wx/include/gtk2-unicode-release-2.6 -I/usr/include/wx-2.6
-DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
-D_LARGEFILE_SOURCE=1 -DNO_GCC_PRAGMA   -DWX_PRECOMP -g -O2
../src/ibpp/ibpp.h:566: error: ‘virtual void IBPP::IRow::Set(int,
int64_t)’ cannot be overloaded
../src/ibpp/ibpp.h:565: error: with ‘virtual void IBPP::IRow::Set(int,
long int)’
../src/ibpp/ibpp.h:583: error: ‘virtual bool IBPP::IRow::Get(int,
int64_t&)’ cannot be overloaded
../src/ibpp/ibpp.h:582: error: with ‘virtual bool IBPP::IRow::Get(int,
long int&)’
../src/ibpp/ibpp.h:600: error: ‘virtual bool IBPP::IRow::Get(const
std::string&, int64_t&)’ cannot be overloaded
../src/ibpp/ibpp.h:599: error: with ‘virtual bool IBPP::IRow::Get(const
std::string&, long int&)’
../src/ibpp/ibpp.h:662: error: ‘virtual void IBPP::IStatement::Set(int,
int64_t)’ cannot be overloaded
../src/ibpp/ibpp.h:661: error: with ‘virtual void
IBPP::IStatement::Set(int, long int)’
../src/ibpp/ibpp.h:684: error: ‘virtual bool IBPP::IStatement::Get(int,
int64_t*)’ cannot be overloaded
../src/ibpp/ibpp.h:682: error: with ‘virtual bool
IBPP::IStatement::Get(int, long int*)’
../src/ibpp/ibpp.h:685: error: ‘virtual bool IBPP::IStatement::Get(int,
int64_t&)’ cannot be overloaded
../src/ibpp/ibpp.h:683: error: with ‘virtual bool
IBPP::IStatement::Get(int, long int&)’
../src/ibpp/ibpp.h:709: error: ‘virtual bool IBPP::IStatement::Get(const
std::string&, int64_t*)’ cannot be overloaded
../src/ibpp/ibpp.h:707: error: with ‘virtual bool
IBPP::IStatement::Get(const std::string&, long int*)’
../src/ibpp/ibpp.h:710: error: ‘virtual bool IBPP::IStatement::Get(const
std::string&, int64_t&)’ cannot be overloaded
../src/ibpp/ibpp.h:708: error: with ‘virtual bool
IBPP::IStatement::Get(const std::string&, long int&)’
make: *** [.pch/ibpp/ibpp.h.gch] Error 1

AFAICT, the problem is that on amd64 the int64_t and long int types are
no longer the same thing.

I don't have experience in fixing this kind of problem (my primary
development language is perl, which has four types: scalar, array, hash
and reference :-) so any help is welcome.


Thanks in advance,
dam
--
Damyan Ivanov          0x9725F63B          Creditreform Bulgaria
[hidden email]              http://www.creditreform.bg/
phone: +359(2)928-2611, 929-3993            fax: +359(2)920-0994
mob. +359(88)856-6067  ICQ 3028500  [hidden email]/Gaim


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: compiling on amd64

Olivier Mascia
On Tue, 20 Sep 2005 21:38:47 +0300,
Damyan Ivanov <[hidden email]> wrote:

DI> $ make
DI> ./bk-make-pch .pch/ibpp/ibpp.h.gch ibpp.h g++ -I.pch/ibpp -DIBPP_GCC
DI> -DIBPP_LINUX -I../src/ibpp -I../src/ibpp/fbheaders
DI> -I/usr/lib/wx/include/gtk2-unicode-release-2.6 -I/usr/include/wx-2.6
DI> -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
DI> -D_LARGEFILE_SOURCE=1 -DNO_GCC_PRAGMA   -DWX_PRECOMP -g -O2
DI> ../src/ibpp/ibpp.h:566: error: ‘virtual void IBPP::IRow::Set(int,
DI> int64_t)’ cannot be overloaded
DI> ../src/ibpp/ibpp.h:565: error: with ‘virtual void IBPP::IRow::Set(int,
DI> long int)’
DI>
DI> AFAICT, the problem is that on amd64 the int64_t and long int types are
DI> no longer the same thing.

I'd write the reverse. I fear int64_t is erroneously declared as
something like long int instead of long long on your platform. Check
wether your compiler supports the C99 (§7.18) integer types definitions
correctly. If it doesn'tn then it might require some specific support
just as this was the case for Windows MSVC6.0 and 7.x.

#if defined(IBPP_MSVC)
typedef __int64 int64_t;
#else
#include <stdint.h> // C99 (§7.18) integer types definitions
#endif

To date, MSVC is the only compiler I found which didn't provided
a suitable stdint.h header file.

--
Olivier Mascia <om at tipgroup dot com>




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: compiling on amd64

Michael Hieke-2
In reply to this post by Damyan Ivanov
Damyan,

Damyan Ivanov wrote:

> Hi,
>
> I've just tried to compile flamerobin on my home amd64 machine and it
> failed :-(
>
> AFAICT, the problem is that on amd64 the int64_t and long int types
> are no longer the same thing.

I'd say it's the other way around, the methods can not be created
because int64_t and long int are the same type on AMD64.  An #ifdef with
a check for size around either int64_t or long int methods should do.
If you want to make it work *now*, just uncomment one set of methods.

Thanks

--
Michael Hieke


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: compiling on amd64

Damyan Ivanov
In reply to this post by Olivier Mascia
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Olivier, Michael,

Olivier Mascia wrote:

> On Tue, 20 Sep 2005 21:38:47 +0300,
> Damyan Ivanov <[hidden email]> wrote:
>
> DI> $ make
> DI> ./bk-make-pch .pch/ibpp/ibpp.h.gch ibpp.h g++ -I.pch/ibpp -DIBPP_GCC
> DI> -DIBPP_LINUX -I../src/ibpp -I../src/ibpp/fbheaders
> DI> -I/usr/lib/wx/include/gtk2-unicode-release-2.6 -I/usr/include/wx-2.6
> DI> -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
> DI> -D_LARGEFILE_SOURCE=1 -DNO_GCC_PRAGMA   -DWX_PRECOMP -g -O2
> DI> ../src/ibpp/ibpp.h:566: error: �virtual void IBPP::IRow::Set(int,
> DI> int64_t)� cannot be overloaded
> DI> ../src/ibpp/ibpp.h:565: error: with �virtual void IBPP::IRow::Set(int,
> DI> long int)�
> DI>
> DI> AFAICT, the problem is that on amd64 the int64_t and long int types are
> DI> no longer the same thing.
>
> I'd write the reverse. I fear int64_t is erroneously declared as
> something like long int instead of long long on your platform. Check

Well, I am not C expert as already stated, so what is obvious to you is
new experience for me. Sorry.

> wether your compiler supports the C99 (§7.18) integer types definitions
> correctly. If it doesn'tn then it might require some specific support
> just as this was the case for Windows MSVC6.0 and 7.x.
>
> #if defined(IBPP_MSVC)
> typedef __int64 int64_t;
> #else
> #include <stdint.h> // C99 (§7.18) integer types definitions
> #endif
>
> To date, MSVC is the only compiler I found which didn't provided
> a suitable stdint.h header file.

This is libc6-dev 2.3.5, gcc-4.0.1, on an i386 box:

/usr/include/stdint.h

# if __WORDSIZE == 64
typedef long int                int64_t;
# else
__extension__
typedef long long int           int64_t;
# endif

I guess it is the same on the amd64 box at home (I can't check right
now) with the obvious difference that on amd64 __WORDSIZE *is* 64.

Your guess about int64_t being long int is right. Whether this is right
or wrong, I cannot say.

So perhaps one set of the overloaded methods above should be wrapped
with # if __WORDSIZE != 64  ?

Or, if the intention of overloading the methods was to give both 64-bit
and 32-bit interface, than perhaps 32-bit variants should use hardcoded
32-bit datatypes (int or int32_t)?



dam
- --
Damyan Ivanov          0x9725F63B          Creditreform Bulgaria
[hidden email]              http://www.creditreform.bg/
phone: +359(2)928-2611, 929-3993            fax: +359(2)920-0994
mob. +359(88)856-6067  ICQ 3028500  [hidden email]/Gaim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDMRhPHqjlqpcl9jsRAkaOAJ4nYy1iI52qt76NIPNiGKgLFzdcKgCgkrwC
JzR9i3ABbCruz2l0BzoMa70=
=OHvq
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: compiling on amd64

Olivier Mascia
On Wed, 21 Sep 2005 11:22:39 +0300,
Damyan Ivanov <[hidden email]> wrote:

DI> This is libc6-dev 2.3.5, gcc-4.0.1, on an i386 box:
DI> /usr/include/stdint.h
DI>
DI> # if __WORDSIZE == 64
DI> typedef long int                int64_t;
DI> # else
DI> __extension__
DI> typedef long long int           int64_t;
DI> # endif

Short answer:
This is what I expected to find in the include file.
But I didn't expected the compiler to not consider long int a distinct
type from long long int, even though both are 64 bits.

Long answer:
The discrepancy at hand is that both 32 bits compilers and 64 compilers
treat int and long as _distinct_ types, even though (on 32 bits) they
are of the same number of bits. You can declare two overloads taking int
and long on 32 bits compilers even though both are actually 32 bits.
This was done to help migration of 16 bits code where int and long where
actually different.

But on your AMD64 gcc that rule does not apply between long and long
long. The compiler doesn't treat them as distinct types. And refuses the
overload. That is really annoying. Wether this is the expected thing on
64 bits compilers or not, I will have to check by reading the ABI
description of various platforms, before deciding on the Right(tm) thing
to do.

For now, I would suggest to comment out the long overloads and keep only
the int and int64_t versions.

--
Olivier Mascia <om at tipgroup dot com>




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: [SOLVED] compiling on amd64

Damyan Ivanov
Olivier,

Olivier Mascia wrote:

> On Wed, 21 Sep 2005 11:22:39 +0300,
> Damyan Ivanov <[hidden email]> wrote:
>
> DI> This is libc6-dev 2.3.5, gcc-4.0.1, on an i386 box:
> DI> /usr/include/stdint.h
> DI>
> DI> # if __WORDSIZE == 64
> DI> typedef long int                int64_t;
> DI> # else
> DI> __extension__
> DI> typedef long long int           int64_t;
> DI> # endif
>
> Short answer:
> This is what I expected to find in the include file.
Good.
> But I didn't expected the compiler to not consider long int a distinct
> type from long long int, even though both are 64 bits.
Sad. :-)

> Long answer:
Thanks for the explanation.

> For now, I would suggest to comment out the long overloads and keep only
> the int and int64_t versions.
Done. It works :-) I've applied the same technique to some method
declarations that existed both in long and int64_t variants. All
removals wrapped with #ifdef __WORDSIZE != 64, so no harm is done on
32-bit builds. See attached ibpp-64.dpatch

I had to change several casts in FR too, due to the fact that a pointer
on amd64 is bigger than an int. It might be better to change %d to %p
and remove the cast, but I wanted to keep changes minimal. Patch
attached (amd64-invalid-casts.dpatch).


In general, FR compiled and works (I've tested it with employee.fdb)
just fine on amd64. Great!


Please consider whether attached patches should be applied.

Thanks,
dam
--
Damyan Ivanov          0x9725F63B          Creditreform Bulgaria
[hidden email]              http://www.creditreform.bg/
phone: +359(2)928-2611, 929-3993            fax: +359(2)920-0994
mob. +359(88)856-6067  ICQ 3028500  [hidden email]/Gaim


#! /bin/sh /usr/share/dpatch/dpatch-run
## ibpp-64.dpatch by  <[hidden email]>
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Fix double declarations of methods that use long and int64_t.
## DP: On amd64 (and probably ia64) both types are the same

@DPATCH@
diff -urNad flamerobin-0.4.0~/src/ibpp/array.cpp flamerobin-0.4.0/src/ibpp/array.cpp
--- flamerobin-0.4.0~/src/ibpp/array.cpp 2005-09-22 13:58:45.000000000 +0300
+++ flamerobin-0.4.0/src/ibpp/array.cpp 2005-09-22 13:58:45.000000000 +0300
@@ -289,7 +289,7 @@
  throw LogicExceptionImpl("Array::ReadTo", "Wrong count of array elements");
 
  IBS status;
- long lenbuf = mBufferSize;
+ ISC_LONG lenbuf = mBufferSize;
  (*gds.Call()->m_array_get_slice)(status.Self(), mDatabase->GetHandlePtr(),
  mTransaction->GetHandlePtr(), &mId, &mDesc, mBuffer, &lenbuf);
  if (status.Errors())
@@ -1088,7 +1088,7 @@
  }
 
  IBS status;
- long lenbuf = mBufferSize;
+ ISC_LONG lenbuf = mBufferSize;
  (*gds.Call()->m_array_put_slice)(status.Self(), mDatabase->GetHandlePtr(),
  mTransaction->GetHandlePtr(), &mId, &mDesc, mBuffer, &lenbuf);
  if (status.Errors())
diff -urNad flamerobin-0.4.0~/src/ibpp/ibpp.h flamerobin-0.4.0/src/ibpp/ibpp.h
--- flamerobin-0.4.0~/src/ibpp/ibpp.h 2005-09-22 13:58:45.000000000 +0300
+++ flamerobin-0.4.0/src/ibpp/ibpp.h 2005-09-22 13:58:45.000000000 +0300
@@ -562,7 +562,9 @@
  virtual void Set(int, const std::string&) = 0;
  virtual void Set(int, short) = 0;
  virtual void Set(int, int) = 0;
+# if __WORDSIZE != 64
  virtual void Set(int, long) = 0;
+# endif
  virtual void Set(int, int64_t) = 0;
  virtual void Set(int, float) = 0;
  virtual void Set(int, double) = 0;
@@ -579,7 +581,9 @@
  virtual bool Get(int, std::string&) = 0;
  virtual bool Get(int, short&) = 0;
  virtual bool Get(int, int&) = 0;
+# if __WORDSIZE != 64
  virtual bool Get(int, long&) = 0;
+# endif
  virtual bool Get(int, int64_t&) = 0;
  virtual bool Get(int, float&) = 0;
  virtual bool Get(int, double&) = 0;
@@ -596,7 +600,9 @@
  virtual bool Get(const std::string&, std::string&) = 0;
  virtual bool Get(const std::string&, short&) = 0;
  virtual bool Get(const std::string&, int&) = 0;
+# if __WORDSIZE != 64
  virtual bool Get(const std::string&, long&) = 0;
+# endif
  virtual bool Get(const std::string&, int64_t&) = 0;
  virtual bool Get(const std::string&, float&) = 0;
  virtual bool Get(const std::string&, double&) = 0;
@@ -658,7 +664,9 @@
  virtual void Set(int, const std::string&) = 0;
  virtual void Set(int, short value) = 0;
  virtual void Set(int, int value) = 0;
+# if __WORDSIZE != 64
  virtual void Set(int, long value) = 0;
+# endif
  virtual void Set(int, int64_t value) = 0;
  virtual void Set(int, float value) = 0;
  virtual void Set(int, double value) = 0;
@@ -679,8 +687,10 @@
  virtual bool Get(int, short&) = 0;
  virtual bool Get(int, int*) = 0;
  virtual bool Get(int, int&) = 0;
+# if __WORDSIZE != 64
  virtual bool Get(int, long*) = 0;
  virtual bool Get(int, long&) = 0;
+# endif
  virtual bool Get(int, int64_t*) = 0;
  virtual bool Get(int, int64_t&) = 0;
  virtual bool Get(int, float*) = 0;
@@ -704,8 +714,10 @@
  virtual bool Get(const std::string&, short&) = 0;
  virtual bool Get(const std::string&, int*) = 0;
  virtual bool Get(const std::string&, int&) = 0;
+# if __WORDSIZE != 64
  virtual bool Get(const std::string&, long*) = 0;
  virtual bool Get(const std::string&, long&) = 0;
+# endif
  virtual bool Get(const std::string&, int64_t*) = 0;
  virtual bool Get(const std::string&, int64_t&) = 0;
  virtual bool Get(const std::string&, float*) = 0;
diff -urNad flamerobin-0.4.0~/src/ibpp/_internals.h flamerobin-0.4.0/src/ibpp/_internals.h
--- flamerobin-0.4.0~/src/ibpp/_internals.h 2005-09-22 13:58:45.000000000 +0300
+++ flamerobin-0.4.0/src/ibpp/_internals.h 2005-09-22 13:58:45.000000000 +0300
@@ -1004,7 +1004,9 @@
  void Set(int, const std::string&);
  void Set(int, short);
  void Set(int, int);
+# if __WORDSIZE != 64
  void Set(int, long);
+# endif
  void Set(int, int64_t);
  void Set(int, float);
  void Set(int, double);
@@ -1022,7 +1024,9 @@
  bool Get(int, std::string&);
  bool Get(int, short&);
  bool Get(int, int&);
+# if __WORDSIZE != 64
  bool Get(int, long&);
+# endif
  bool Get(int, int64_t&);
  bool Get(int, float&);
  bool Get(int, double&);
@@ -1040,7 +1044,9 @@
  bool Get(const std::string&, std::string&);
  bool Get(const std::string&, short&);
  bool Get(const std::string&, int&);
+# if __WORDSIZE != 64
  bool Get(const std::string&, long&);
+# endif
  bool Get(const std::string&, int64_t&);
  bool Get(const std::string&, float&);
  bool Get(const std::string&, double&);
@@ -1126,7 +1132,9 @@
  void Set(int, const std::string&);
  void Set(int, short);
  void Set(int, int);
+# if __WORDSIZE != 64
  void Set(int, long);
+# endif
  void Set(int, int64_t);
  void Set(int, float);
  void Set(int, double);
@@ -1147,8 +1155,10 @@
  bool Get(int, short&);
  bool Get(int, int*);
  bool Get(int, int&);
+# if __WORDSIZE != 64
  bool Get(int, long*);
  bool Get(int, long&);
+# endif
  bool Get(int, int64_t*);
  bool Get(int, int64_t&);
  bool Get(int, float*);
@@ -1172,8 +1182,10 @@
  bool Get(const std::string&, short&);
  bool Get(const std::string&, int*);
  bool Get(const std::string&, int&);
+# if __WORDSIZE != 64
  bool Get(const std::string&, long*);
  bool Get(const std::string&, long&);
+# endif
  bool Get(const std::string&, int64_t*);
  bool Get(const std::string&, int64_t&);
  bool Get(const std::string&, float*);
diff -urNad flamerobin-0.4.0~/src/ibpp/row.cpp flamerobin-0.4.0/src/ibpp/row.cpp
--- flamerobin-0.4.0~/src/ibpp/row.cpp 2005-09-22 13:58:45.000000000 +0300
+++ flamerobin-0.4.0/src/ibpp/row.cpp 2005-09-22 13:58:45.000000000 +0300
@@ -161,6 +161,7 @@
  mUpdated[param-1] = true;
 }
 
+# if __WORDSIZE != 64
 void RowImpl::Set(int param, long value)
 {
  if (mDescrArea == 0)
@@ -169,6 +170,7 @@
  SetValue(param, ivLong, &value);
  mUpdated[param-1] = true;
 }
+# endif
 
 void RowImpl::Set(int param, int64_t value)
 {
@@ -380,6 +382,7 @@
  return pvalue == 0 ? true : false;
 }
 
+# if __WORDSIZE != 64
 bool RowImpl::Get(int column, long& retvalue)
 {
  if (mDescrArea == 0)
@@ -390,6 +393,7 @@
  retvalue = *(long*)pvalue;
  return pvalue == 0 ? true : false;
 }
+# endif
 
 bool RowImpl::Get(int column, int64_t& retvalue)
 {
@@ -558,6 +562,7 @@
  return Get(ColumnNum(name), retvalue);
 }
 
+# if __WORDSIZE != 64
 bool RowImpl::Get(const std::string& name, long& retvalue)
 {
  if (mDescrArea == 0)
@@ -565,6 +570,7 @@
 
  return Get(ColumnNum(name), retvalue);
 }
+# endif
 
 bool RowImpl::Get(const std::string& name, int64_t& retvalue)
 {
diff -urNad flamerobin-0.4.0~/src/ibpp/statement.cpp flamerobin-0.4.0/src/ibpp/statement.cpp
--- flamerobin-0.4.0~/src/ibpp/statement.cpp 2005-09-03 14:49:07.000000000 +0300
+++ flamerobin-0.4.0/src/ibpp/statement.cpp 2005-09-22 14:00:27.000000000 +0300
@@ -550,6 +550,7 @@
  mInRow->Set(param, value);
 }
 
+# if __WORDSIZE != 64
 void StatementImpl::Set(int param, long value)
 {
  if (mHandle == 0)
@@ -559,6 +560,7 @@
 
  mInRow->Set(param, value);
 }
+# endif
 
 void StatementImpl::Set(int param, int64_t value)
 {
@@ -748,6 +750,7 @@
  return mOutRow->Get(column, retvalue);
 }
 
+# if __WORDSIZE != 64
 bool StatementImpl::Get(int column, long* retvalue)
 {
  if (mOutRow == 0)
@@ -757,7 +760,9 @@
 
  return mOutRow->Get(column, *retvalue);
 }
+# endif
 
+# if __WORDSIZE != 64
 bool StatementImpl::Get(int column, long& retvalue)
 {
  if (mOutRow == 0)
@@ -765,6 +770,7 @@
 
  return mOutRow->Get(column, retvalue);
 }
+# endif
 
 bool StatementImpl::Get(int column, int64_t* retvalue)
 {
@@ -964,6 +970,7 @@
  return mOutRow->Get(name, retvalue);
 }
 
+# if __WORDSIZE != 64
 bool StatementImpl::Get(const std::string& name, long* retvalue)
 {
  if (mOutRow == 0)
@@ -973,7 +980,9 @@
 
  return mOutRow->Get(name, *retvalue);
 }
+# endif
 
+# if __WORDSIZE != 64
 bool StatementImpl::Get(const std::string& name, long& retvalue)
 {
  if (mOutRow == 0)
@@ -981,6 +990,7 @@
 
  return mOutRow->Get(name, retvalue);
 }
+# endif
 
 bool StatementImpl::Get(const std::string& name, int64_t* retvalue)
 {


#! /bin/sh /usr/share/dpatch/dpatch-run
## amd64-invalid-casts.dpatch by  <[hidden email]>
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Fix invalid casts from pointer to int. On amd64 a pointer is
## DP: bigger than an int.

@DPATCH@
diff -urNad flamerobin-0.4.0~/src/gui/MainFrame.cpp flamerobin-0.4.0/src/gui/MainFrame.cpp
--- flamerobin-0.4.0~/src/gui/MainFrame.cpp 2005-09-22 14:15:57.000000000 +0300
+++ flamerobin-0.4.0/src/gui/MainFrame.cpp 2005-09-22 14:15:58.000000000 +0300
@@ -979,8 +979,8 @@
     if (!g)
         return;
 
-    URI uri = URI("fr://edit_generator_value?parent_window=" + wx2std(wxString::Format(wxT("%d"), (int)this))
-        + "&object_address=" + wx2std(wxString::Format(wxT("%d"), (int)g)));
+    URI uri = URI("fr://edit_generator_value?parent_window=" + wx2std(wxString::Format(wxT("%l"), (long)this))
+        + "&object_address=" + wx2std(wxString::Format(wxT("%l"), (long)g)));
     getURIProcessor().handleURI(uri);
 }
 //-----------------------------------------------------------------------------
diff -urNad flamerobin-0.4.0~/src/gui/MetadataItemPropertiesFrame.cpp flamerobin-0.4.0/src/gui/MetadataItemPropertiesFrame.cpp
--- flamerobin-0.4.0~/src/gui/MetadataItemPropertiesFrame.cpp 2005-09-22 14:15:57.000000000 +0300
+++ flamerobin-0.4.0/src/gui/MetadataItemPropertiesFrame.cpp 2005-09-22 14:15:58.000000000 +0300
@@ -207,10 +207,10 @@
         htmlpage += object->getTypeName();
 
     else if (cmd == "object_address")
-        htmlpage += wx2std(wxString::Format(wxT("%d"), (int)object));
+        htmlpage += wx2std(wxString::Format(wxT("%l"), (long)object));
 
     else if (cmd == "parent_window")
-        htmlpage += wx2std(wxString::Format(wxT("%d"), (int)this));
+        htmlpage += wx2std(wxString::Format(wxT("%l"), (long)this));
 
     else if (cmd == "fr_home")
         htmlpage += config().getHomePath();
diff -urNad flamerobin-0.4.0~/src/myTreeCtrl.cpp flamerobin-0.4.0/src/myTreeCtrl.cpp
--- flamerobin-0.4.0~/src/myTreeCtrl.cpp 2005-09-13 17:15:14.000000000 +0300
+++ flamerobin-0.4.0/src/myTreeCtrl.cpp 2005-09-22 14:16:22.000000000 +0300
@@ -65,7 +65,7 @@
         if (!m)
             return;
         wxString test;
-        test.Printf(wxT("OBJECT:%d"), (int)m);
+        test.Printf(wxT("OBJECT:%l"), (long)m);
         wxTextDataObject textData(test);
         wxDropSource source(textData, this);
         source.DoDragDrop(wxDrag_AllowMove);

Reply | Threaded
Open this post in threaded view
|

Re: [SOLVED] compiling on amd64

Michael Hieke-2
Damyan,

Damyan Ivanov wrote:

> I had to change several casts in FR too, due to the fact that a
> pointer on amd64 is bigger than an int. It might be better to change
> %d to %p and remove the cast, but I wanted to keep changes minimal.
> Patch attached (amd64-invalid-casts.dpatch).
>
> In general, FR compiled and works (I've tested it with employee.fdb)
> just fine on amd64. Great!
>
> Please consider whether attached patches should be applied.

thanks for those patches, but could you please look into the following:

Your patches make FR use %l instead of %d for formatting the typecasted
object addresses.
Do they appear with 16 digits in the resulting HTML source?
And have you ever seen anything else than a 0 in the upper 8 digits
(meaning an address > 4GByte)?
If so, does it still work, using wxString::ToULong() for reading the
address back?

Thanks

--
Michael Hieke


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: compiling on amd64

Damyan Ivanov
Michael Hieke wrote:
> Your patches make FR use %l instead of %d for formatting the typecasted
> object addresses.
> Do they appear with 16 digits in the resulting HTML source?
> And have you ever seen anything else than a 0 in the upper 8 digits
> (meaning an address > 4GByte)?

Where is this html source? Do you mean the properties window? If so,
then there is a problem: the "parent_window" parameter in URIs is always
empty :-( Same with "parent_window" and "object_address"

I guess it was too early for "[SOLVED]".

Replacing %d with %p and removing the case made the above parameters to
have values, but clicking on [edit] for example does nothing. This is
the properties window of a table.

> If so, does it still work, using wxString::ToULong() for reading the address back?

There is the problem - %p generates hexadecimal digits and they don't
parse back. There is no ToPointer function in wxString :-)

So I've changed %d to %ld, instead of just %l and kept the (long) cast.
This made addresses to show up in HTML windows. And links even work :-)
All addresses are 8-digits, but I have only about 3.5G virtual memory,
so this is not surprising. Hopefully ToULong should work for addresses
over 4G.

Modified patch attached.

There is another problem that I need help with.

Clicking on "Dependencies" in a table properties window causes the
following message to appear (two times):

*** IBPP::SQLException ***
Context: RowImpl::SetValue
Message: Out of range numeric conversion !

This is probably due to my fiddling with ibpp, but I can't find anything
wrong there.

Other pages - Constraints, Triggers, Indices and DDL work fine.
As well as Add field, Reorder fields and Drop fields.

Where should I start looking?


dam
--
Damyan Ivanov          0x9725F63B          Creditreform Bulgaria
[hidden email]              http://www.creditreform.bg/
phone: +359(2)928-2611, 929-3993            fax: +359(2)920-0994
mob. +359(88)856-6067  ICQ 3028500  [hidden email]/Gaim

#! /bin/sh /usr/share/dpatch/dpatch-run
## amd64-invalid-casts.dpatch by  <[hidden email]>
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Fix invalid casts from pointer to int. On amd64 a pointer is
## DP: bigger than an int.

@DPATCH@
diff -urNad flamerobin-0.4.0~/src/gui/MainFrame.cpp flamerobin-0.4.0/src/gui/MainFrame.cpp
--- flamerobin-0.4.0~/src/gui/MainFrame.cpp 2005-09-22 14:15:57.000000000 +0300
+++ flamerobin-0.4.0/src/gui/MainFrame.cpp 2005-09-22 14:15:58.000000000 +0300
@@ -979,8 +979,8 @@
     if (!g)
         return;
 
-    URI uri = URI("fr://edit_generator_value?parent_window=" + wx2std(wxString::Format(wxT("%d"), (int)this))
-        + "&object_address=" + wx2std(wxString::Format(wxT("%d"), (int)g)));
+    URI uri = URI("fr://edit_generator_value?parent_window=" + wx2std(wxString::Format(wxT("%ld"), (long)this))
+        + "&object_address=" + wx2std(wxString::Format(wxT("%ld"), (long)g)));
     getURIProcessor().handleURI(uri);
 }
 //-----------------------------------------------------------------------------
diff -urNad flamerobin-0.4.0~/src/gui/MetadataItemPropertiesFrame.cpp flamerobin-0.4.0/src/gui/MetadataItemPropertiesFrame.cpp
--- flamerobin-0.4.0~/src/gui/MetadataItemPropertiesFrame.cpp 2005-09-22 14:15:57.000000000 +0300
+++ flamerobin-0.4.0/src/gui/MetadataItemPropertiesFrame.cpp 2005-09-22 14:15:58.000000000 +0300
@@ -207,10 +207,10 @@
         htmlpage += object->getTypeName();
 
     else if (cmd == "object_address")
-        htmlpage += wx2std(wxString::Format(wxT("%d"), (int)object));
+        htmlpage += wx2std(wxString::Format(wxT("%ld"), (long)object));
 
     else if (cmd == "parent_window")
-        htmlpage += wx2std(wxString::Format(wxT("%d"), (int)this));
+        htmlpage += wx2std(wxString::Format(wxT("%ld"), (long)this));
 
     else if (cmd == "fr_home")
         htmlpage += config().getHomePath();
diff -urNad flamerobin-0.4.0~/src/myTreeCtrl.cpp flamerobin-0.4.0/src/myTreeCtrl.cpp
--- flamerobin-0.4.0~/src/myTreeCtrl.cpp 2005-09-13 17:15:14.000000000 +0300
+++ flamerobin-0.4.0/src/myTreeCtrl.cpp 2005-09-22 14:16:22.000000000 +0300
@@ -65,7 +65,7 @@
         if (!m)
             return;
         wxString test;
-        test.Printf(wxT("OBJECT:%d"), (int)m);
+        test.Printf(wxT("OBJECT:%ld"), (long)m);
         wxTextDataObject textData(test);
         wxDropSource source(textData, this);
         source.DoDragDrop(wxDrag_AllowMove);
Reply | Threaded
Open this post in threaded view
|

Re: compiling on amd64

Michael Hieke-2
Damyan,

Damyan Ivanov wrote:

> Where is this html source? Do you mean the properties window?

Yes.

> If so, then there is a problem: the "parent_window" parameter in URIs
> is always empty :-( Same with "parent_window" and "object_address"
>
> I guess it was too early for "[SOLVED]".
>
> Replacing %d with %p and removing the case made the above parameters
> to have values, but clicking on [edit] for example does nothing. This
> is the properties window of a table.

I can only repeat my earlier opinion about those URIs - all of this is
way too system-dependent.  We need to use handles for those references
to objects and frames, either string or integer handles.

> There is the problem - %p generates hexadecimal digits and they don't
> parse back. There is no ToPointer function in wxString :-)

Which is a good thing, IMO :-)

> So I've changed %d to %ld, instead of just %l and kept the (long)
> cast. This made addresses to show up in HTML windows. And links even
> work :-) All addresses are 8-digits, but I have only about 3.5G
> virtual memory, so this is not surprising. Hopefully ToULong should
> work for addresses over 4G.

I don't think so.  What's missing is ToULongLong(), and << or standard
format specifier for 64-bit quantities, all for wxString.
Still, it's a hack.

> Clicking on "Dependencies" in a table properties window causes the
> following message to appear (two times):
>
> *** IBPP::SQLException ***
> Context: RowImpl::SetValue
> Message: Out of range numeric conversion !
>
> This is probably due to my fiddling with ibpp, but I can't find
> anything wrong there.

Interesting.  Problem may as well be in FR.  Can you build wx and FR
with --enable-debug, run under GDB and provide a stacktrace?

Maybe I should install a 64-bit Linux on my home machine.  Any tip for a
good distribution, given that I'm the Slackware type of user?

Thanks

--
Michael Hieke


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: compiling on amd64

Damyan Ivanov
Michael Hieke wrote:
>> So I've changed %d to %ld, instead of just %l and kept the (long)
>> cast. This made addresses to show up in HTML windows. And links even
>> work :-) All addresses are 8-digits, but I have only about 3.5G
>> virtual memory, so this is not surprising. Hopefully ToULong should
>> work for addresses over 4G.
>
> I don't think so.  What's missing is ToULongLong(), and << or standard
> format specifier for 64-bit quantities, all for wxString.
> Still, it's a hack.

Hmm. My analogy was that since "long" means 64bits on amd64, maybe toULong
works with 64-bit unsigned integers on amd64 too. Didn't look in any
documents, though so I may be wrong.

>> Clicking on "Dependencies" in a table properties window causes the
>> following message to appear (two times):
>>
>> *** IBPP::SQLException ***
>> Context: RowImpl::SetValue
>> Message: Out of range numeric conversion !
>>
>> This is probably due to my fiddling with ibpp, but I can't find
>> anything wrong there.
>
> Interesting.  Problem may as well be in FR.  Can you build wx and FR
> with --enable-debug, run under GDB and provide a stacktrace?

I'll try.
Or put additional information in the exception so one can tell which one
it is (there are several "Out of range numeric conversion"s in row.cpp)

> Maybe I should install a 64-bit Linux on my home machine.  Any tip for a
> good distribution, given that I'm the Slackware type of user?

slamd64.com seems appropriate.

It's never late to try Debian too :-) amd64.debian.net


dam
--
Damyan Ivanov          0x9725F63B          Creditreform Bulgaria
[hidden email]              http://www.creditreform.bg/
phone: +359(2)928-2611, 929-3993            fax: +359(2)920-0994
mob. +359(88)856-6067  ICQ 3028500  [hidden email]/Gaim


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: compiling on amd64

Milan Babuskov-2
In reply to this post by Michael Hieke-2
Michael Hieke wrote:
> Maybe I should install a 64-bit Linux on my home machine.  Any tip for a
> good distribution, given that I'm the Slackware type of user?

Use Slackware then:

http://www.slamd64.com/

--
Milan Babuskov
http://www.flamerobin.org



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: compiling on amd64

Michael Hieke
In reply to this post by Damyan Ivanov
Damyan,

Damyan Ivanov wrote:

> Hmm. My analogy was that since "long" means 64bits on amd64, maybe
> toULong works with 64-bit unsigned integers on amd64 too. Didn't look
> in any documents, though so I may be wrong.

AFAIR the width of long is up to the compiler vendor, and there are
indeed different implementations.  So while it may work on Linux, it may
not with MSVC.  Don't know exactly, though.

Thanks

--
Michael Hieke


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: compiling on amd64

Olivier Mascia
On Thu, 22 Sep 2005 17:05:43 +0200,
Michael Hieke <[hidden email]> wrote:

MH> AFAIR the width of long is up to the compiler vendor, and there are
MH> indeed different implementations.  So while it may work on Linux, it may
MH> not with MSVC.  Don't know exactly, though.

Okay, this is the paper to read:

http://www.unix.org/version2/whatsnew/lp64_wp.html

AMD64 adheres to LP64 model as most other vendors are doing or are
likely to be doing. So int is 32 bits as in 32 bits models and long is
64 bits (and is guaranteed to be able to hold a pointer).

Regarding IBPP, I won't touch anything right now. I would most probably
introduce some IBPP_LP64 define to adjust internal code where
appropriate. For instance, it is now absolutely clear that offering int,
long and long long (or int64_t) types will go nowhere as int (32) and
long (64) are sufficient.

Yet, on 32 bits worlds this is required. Because IBPP users must be able
to access FB 64 bits data (like generators for instance) or like
NUMERIC(18,0), which are actually stored as a 64 bits integer in dialect
3.

So first thing first, I have to check with FB how their header files are
going to declare the various sizes of information they handle. From that
and nothing else will come the choices regarding the exact interfaces to
expose. In between, I checked the code and yes, hiding int64_t
prototypes and simply using the long ones won't do the trick. There are
clear assumptions and even runtime checks that long is 32 bits and no
more, hence the out of range numeric conversion exceptions seen today.

Then will come some weird conversions, unless the FB API in 64 bits mode
helps.

--
Olivier Mascia <om at tipgroup dot com>




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: compiling on amd64

Michael Hieke
Olivier,

Olivier Mascia wrote:

> AMD64 adheres to LP64 model as most other vendors are doing or are
> likely to be doing. So int is 32 bits as in 32 bits models and long
> is 64 bits (and is guaranteed to be able to hold a pointer).

but what about this
(http://msdn.microsoft.com/visualc/using/building/64bit/default.aspx?pull=/library/en-us/dnnetserv/html/ws03-64-bitwindevover.asp):

> The 64-bit version of Windows uses the LLP64 data model. What this
> means is that the standard C types int and long remain 32-bit
> integers. The data type size_t is mapped to the processor's word size
> (32-bits for IA32 and 64-bits for IA64), and __int64 is a 64-bit
> integer. This was done to assist in porting 32-bit code.

I would in any case go with the C99 standard, which says that long is
*at least* 32 bits, while long long is *at least* 64.

> For instance, it is now absolutely clear that offering int, long and
> long long (or int64_t) types will go nowhere as int (32) and long
> (64) are sufficient.

See above.  Why not go with the standard?  long is not 64, it is 32(+).

> Yet, on 32 bits worlds this is required. Because IBPP users must be able
> to access FB 64 bits data (like generators for instance) or like
> NUMERIC(18,0), which are actually stored as a 64 bits integer in dialect
> 3.

IMHO you should just use int32_t, int64_t etc. and define those for the
compilers that don't have stdint.h.

Thanks

--
Michael Hieke


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: compiling on amd64

Olivier Mascia
On Thu, 22 Sep 2005 19:34:59 +0200,
Michael Hieke <[hidden email]> wrote:

MH> but what about this
MH>
MH> > The 64-bit version of Windows uses the LLP64 data model. What this
MH> > means is that the standard C types int and long remain 32-bit
MH> > integers. The data type size_t is mapped to the processor's word size
MH> > (32-bits for IA32 and 64-bits for IA64), and __int64 is a 64-bit
MH> > integer. This was done to assist in porting 32-bit code.

Yeah. Your message crossed my "64-bit-ization - rough first pass" commit
I just made to the rel_2_4 branch.

MH> I would in any case go with the C99 standard, which says that long is
MH> *at least* 32 bits, while long long is *at least* 64.
MH> ...
MH> See above.  Why not go with the standard?  long is not 64, it is 32(+).

That's what I actually did in that first pass. It was anyway the easiest
way to formulate the right solution.

MH> IMHO you should just use int32_t, int64_t etc. and define those for the
MH> compilers that don't have stdint.h.

Exactly what happens now in ibpp.h.
We'll start some large scale tests, first to verify that on 32bits
platforms we routinely use, it compiles just fine and runs just fine.

Woops : can someone confirm me if there are known problems with commits
on sourceforge CVS ?  My commit just timed out for 3 times in a row.
I'll pack the code and attempt commit from home tonight.

I don't recommend anyone to rush and check-out that work now anyway.

--
Olivier Mascia <om at tipgroup dot com>




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: compiling on amd64

Milan Babuskov-2
Olivier Mascia wrote:
> Woops : can someone confirm me if there are known problems with commits
> on sourceforge CVS ?  My commit just timed out for 3 times in a row.
> I'll pack the code and attempt commit from home tonight.
>
> I don't recommend anyone to rush and check-out that work now anyway.

Especially since anonymous CVS is always half-day behind.

BTW, Olivier, do you use some IM?

--
Milan Babuskov
http://www.flamerobin.org



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: compiling on amd64

marius adrian popa
Administrator
In reply to this post by Olivier Mascia
On 9/22/05, Olivier Mascia <[hidden email]> wrote:

> On Thu, 22 Sep 2005 19:34:59 +0200,
> Michael Hieke <[hidden email]> wrote:
>
> MH> but what about this
> MH>
> MH> > The 64-bit version of Windows uses the LLP64 data model. What this
> MH> > means is that the standard C types int and long remain 32-bit
> MH> > integers. The data type size_t is mapped to the processor's word size
> MH> > (32-bits for IA32 and 64-bits for IA64), and __int64 is a 64-bit
> MH> > integer. This was done to assist in porting 32-bit code.
>
> Yeah. Your message crossed my "64-bit-ization - rough first pass" commit
> I just made to the rel_2_4 branch.
>
> MH> I would in any case go with the C99 standard, which says that long is
> MH> *at least* 32 bits, while long long is *at least* 64.
> MH> ...
> MH> See above.  Why not go with the standard?  long is not 64, it is 32(+).
>
> That's what I actually did in that first pass. It was anyway the easiest
> way to formulate the right solution.
>
> MH> IMHO you should just use int32_t, int64_t etc. and define those for the
> MH> compilers that don't have stdint.h.

o used uintptr_t (just commited into cvs) , someone should check it if
works ok on 32 bit

>
> Exactly what happens now in ibpp.h.
> We'll start some large scale tests, first to verify that on 32bits
> platforms we routinely use, it compiles just fine and runs just fine.
>
> Woops : can someone confirm me if there are known problems with commits
> on sourceforge CVS ?  My commit just timed out for 3 times in a row.
> I'll pack the code and attempt commit from home tonight.
>
> I don't recommend anyone to rush and check-out that work now anyway.

i checked out last version and now seems to compile fine on 64bit

cvs -z3 -d:pserver:[hidden email]:/cvsroot/ibpp co -r
rel_2_4 -P ibpp2

when should we use rel_2_4 version in flamerobin's cvs tree ?


--
developer flamerobin.org


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel