dolibarr-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Dolibarr-dev] [task #10203] Génération auto du code produit


From: Laurent Destailleur
Subject: [Dolibarr-dev] [task #10203] Génération auto du code produit
Date: Sat, 27 Feb 2010 14:26:20 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8

URL:
  <http://savannah.nongnu.org/task/?10203>

                 Summary: Génération auto du code produit
                 Project: Dolibarr
            Submitted by: mrcooll
            Submitted on: sam 27 fév 2010 15:26:19 CET
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                 Release: None
        Operating System: None

    _______________________________________________________

Details:

La génération d'un code doit être automatique au lieu d'un réf. produit
à saisir manuellement

    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: mer 16 fév 2005 19:46:36 CET By: Julio M. Merino Vidal <jmmv>
Well, in fact, I've just applied a patch to use uint{8,16,32,64}_t types as
some other code in Monotone does (so it doesn't reduce portability); should
avoid multiple problems of this kind.  Anyway, this doesn't fix the fact that
cryptopp's config.h is a royal PITA to fix portability issues and maintain.

Marking this bug as closed since the submitter is unknown.

-------------------------------------------------------
Date: mer 16 fév 2005 16:51:42 CET By: Julio M. Merino Vidal <jmmv>
As the previous comment says, this is a problem in cryptopp, not in monotone
(although we should import any fixes done in the original library).

However, I can't see why this fails.  I've fetched a copy of the code from
the date you filled the bug, and the line that's triggering the problem
(unless I've done some mistake) is the following, from cryptopp/cryptlib.cpp:

CRYPTOPP_COMPILE_ASSERT(sizeof(word32) == 4);

So the problem has to be that the size of the 'word32' type is not 4 bytes in
the machine you are building the program.  (Well, cryptopp is checking for
portability issues in an extremely ugly way, but anyway...  not something we
want to fix, probably.)

word32 is also an alias for unsigned int in the code.  I've looked at what
NetBSD does in a sparc64 machine and also checked an IRIX64 systems.  In both
of them, the size of 'unsigned int' is 4 bytes, which matches the expected
value.  (I doubt this changes between OSes... right?)

So I don't know how/why this happens in your FreeBSD/sparc64 system.  May it
be that it has different expectations?  Anybody knows or has a FreeBSD/sparc64
machine on which he can run a few tests?  (Asking in general because the bug
is anonymous; will have to close it if nobody pops up...)

-------------------------------------------------------
Date: ven 15 oct 2004 12:08:31 CEST By: Bernhard Reiter <bernhard>
The failure seems to be in the cryptopp part
e.g. cryptopp/algebra.cpp
Those file probably originated from http://www.cryptopp.com.
If you want to progress this bug, you could try to compile
a recent version of cryptopp and possibly file the bug
with them or try to update monotones files with newer ones
from cryptopp, if possible.





    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: dim 29 aoû 2004 07:21:07 CEST  Name: log  Size: 9 ko   By: None
compilation log
<http://savannah.nongnu.org/bugs/download.php?file_id=1694>

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?10203>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]