Re: Already generated files are not generated a second time because
Hi, You should only have to modify objects.txt, the others are all updated from it. That's the point, the others are not updated if all the files have the same date. Yes, make completely relies on dates to decide what files need to be generated and which ones are up-to-date. Just try touch some_file_which_should_be_build.o in the right directory and you'll see the build either use the empty object file you just created by touch or fail with an error message when trying to use that empty object file, depending on platform/compiler. Using cp -p instead of just cp avoids that issue by keeping the original dates and times of the files you copy... Stefan. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Help crash on IO_proc_close/ CRYPTO_free !
Hi, Core 1 -- (gdb) bt #0 0x4021e76e in pclose () from /lib/libc.so.6 #1 0x4021e548 in _IO_proc_close () from /lib/libc.so.6 #2 0x400b4772 in CRYPTO_free (str=0x0) at mem.c:380 (gdb) And if I read that backtrace in the correct direction, Sorry to interrupt, but no, you didn't read it in the correct direction. It's pclose being called by _IO_proc_close which in turn was called by CRYPTO_free... _I_ would suspect my own code and since this yaks about a pclose() my first question to the team would be: what have we got on pipes in our project? And see if you can put some diagnostics around it. Either that or a completely corrupted stack or heap, in which case something like valgrind or purify is probably going to be helpful in finding the _real_ problem. And while you're at it, and assuming you're in a multithreaded app, check whether the OpenSSL thread lock hooks are done properly, just to cover all the bases. (snipp) My bet is some part of your software has gone totally bonkers. With OpenSSL being part of the collateral. Agreed. Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1753] snapshot 20081003 broke mingw build
Hi, 5. Added -DWIN32_LEAN_AND_MEAN and drop the conflict undef of x509.h While I don't mind having to compile the library itself with special flags, the above implies that every _user_ of OpenSSL who includes x509.h has to either use -DWIN32_LEAN_AND_MEAN as well or that he is going to have to add those undefs himself, so IMHO this is something which really should be done by openssl headers themselves, even if that means a bit more work and occassionally doesn't work (i.e. when MS adds yet another conflicting definition to their headers...). Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
Hi, If feeding predictable data into a PRNG that was already well seeded with unpredictable data produced a weaker PRNG, then you have found a security bug in the PRNG and I suggest you publish. Yeah, I've heard that a few times. However, consider the pathological case, in which an adversary manages to introduce N-1 bits of known state into your PRNG which has N bits of internal state. Are you comfortable with that? Yes and no. No, because I don't like it, if an attacker even knows a single bit of the internal state of the PRNG. But yes, because it simply doesn't work the way your question makes it seem: If you add known bits to the state, those do _not_ simply replace the state bits but are mixed into it. If you have N state bits, even if you add N^2 or 2^N or whatever bits to the state, you still don't know any single bit of the state. I'll give a simplified example on how this mixing in works, so you can see yourself, why everybody is confident about this: Think of adding bits of known state as really adding N bit numbers via standard addition (ignoring the overflow bit, i.e. addition modulo 2^N). So you have an unknown state and add a known number to it (or any number of known numbers). You still don't know the sum, i.e. the internal state is still perfectly safe. And vice versa, if you do know the resulting state (or even a single bit in it), you can simply do a subtraction and get to know the original state (or the corresponding single bit in it), i.e. if the new state is predictable, so is the original one, i.e. you don't loose any security. On the other hand, if an attacker got to know some bits of the internal state and you add N unknown bits into the state, the result will be unknown again. So the worst case (all bits are known) doesn't do any harm, while the best case (some bits are really unpredictable) is really helpful. HTH, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: valgrind and openssl
Hi, It certainly would, but Valgrind isn't the only analysis tool people might want to use. A runtime flag provides a means of obtaining accurate results with any tool. Unfortunately, for am attacker it also provides a means of (possibly) weakening your program's randomness behind your back, so IMO any way to configure this behaviour at runtime is a potential security issue. IMO it's better to tell people unable to ignore bogus warnings (or make their analysis tool ignore them, e.g. via a suppressions file) to use a special build option, like it's currently done. In fact, I'd generally (i.e. not specifically for OpenSSL) wish developers would invest more of their time into fixing bugs and/or adding features rather than trying to get rid of the last bogus warnings caused by some more or less obscure compiler or analysis tool - that would also (need to) result in a healthier reaction to such warnings by other developers and packagers: just assume that the authors know what they are doing instead of trying to fix even the last warning by whatever inappropriate means. Regards, Stefan P.S.: Of course, I realize it's a problem if you have lots of bogus warnings and can't even find the real problematic ones in between them, but there must be a reasonable compromise somewhere between a lot and zero. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Makefile for building openssl for windows using mingw32 on linux
Hi, There are a lot of issues with mingw32 out there... Examples: http://rt.openssl.org/Ticket/Display.html?id=1451 http://rt.openssl.org/Ticket/Display.html?id=1511 http://rt.openssl.org/Ticket/Display.html?id=1552 But none are added into the snapshot... Why not? Because the developpers don't want to support several different ways to reach the same goal, so they did choose to add cross-compilation support in a somewhat different way ... Do you not want people to easily cross-compile openssl for Windows on the linux boxes? They do. The basic idea is that ideally, just doing 'CROSS_COMPILE_PREFIX=i386-mingw32- ./Configure mingw' followed by 'make' should work (Of course, use whatever is appropriate in your installation instead of i386-mingw32-). However, that's just the theory, that I gathered from by following the mailing list, I don't know how well this approach does already work in practice (particularly, I don't know about the 0.9.8 releases, they seemed to be mostly busy with trying this on what is going to be 0.9.9). Also, it's been some time since my last cross-compile of OpenSSL, so I didn't try this yet... HTH, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Not able to find code MD5_Update() ,SHA1_Update() and more digest function
Hi, If I call MD5_Update / Final / SHA_Update/ final ... all these functions are replaced by macros or ... ? No. The functions are there just fine. _Implementing_ them uses the macros. #define HASH_UPDATE SHA1_Update HASH_UPDATE will be replaced by the SHA1_Update .. is it so ? No, it's the other way round: To define what SHA1_Update does, the more general HASH_UPDATE macro is used. if some thing like that where can find definition for SHA1_Update As Gerrit already said: When you look for SHA1_Update you'll find that crypto/sha will apply the same mechanism: #define HASH_UPDATE SHA1_Update and one more #include of md32_common.h, thus actually reusing the code in md32_common.h . So the definition for SHA1_Update is in that file with the #define HASH_UPDATE SHA1_Update It just internally uses the macro to implement it. It somewhat confusing, but you can use your preprocessor to understand what's going on. Passing a -E (or /E) instead of -c (or /c) to the command line that compiles the actual file should give you the preprocessor output, i.e. the code that the compiler actually gets to see after the macro substitutions did take place - that might help to understand what's actually going on... HTH, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1520] request for checking if -in and -out files are same
Hi, I don't see why these assumptions cannot be done at compile time. There exists few different filesystem semanctics: Unix one, DOS/Windows one, VMS (versioned) one. How do you know which one to use? In our networked world it's difficult to know what kind of filesystems you're going to use. E.g. on my system with it's windows like native filesystem I'm almost exclusively accessing SMB or NFS mounted Unix filesystems... Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1504] Padding bug in 0.9.8d (Solaris 9, Sparc)
Nils Larsch via RT schrieb: openssl doesn't support the type of padding (0x80, 0x00, 0x00, ...) you are using (openssl only supports the padding described in pkcs7). In that case, any idea why it does happen to work with version 0.9.8? Assuming that wasn't intended, it sure seems like a very strange coincidence... Try decrypting it without padding (using the EVP_CIPH_NO_PADDING flag) and remove the padding yourself. OK, will do. Thanks, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1504] Padding bug in 0.9.8d (Solaris 9, Sparc)
Hi, Any feedback about my problem? Can anybody confirm the padding bug shown by my sample code (see RT) or can nobody reproduce it (e.g. because I forgot to mention that I'm using a static build...)? Best, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1504] Padding bug in 0.9.8d (Solaris 9, Sparc)
Hi, I'm totally confused by a difference I'm observing between openssl-0.9.8 and openssl-0.9.8d, both compiled on the same solaris box with the same compiler installation (gcc-3.4.4), both passing make test. I'm decrypting a DES-encrypted message, that was padded with 80 00 00 00 00 00 00 00 (in hex code) before encryption. The essential lines of code are as follows: EVP_CIPHER_CTX ctx_des; EVP_DecryptInit(ctx_des, EVP_des_ede_cbc(), key, NULL); out = (BYTE*)malloc(inlen + EVP_CIPHER_block_size(EVP_des_ede_cbc())); EVP_DecryptUpdate(ctx_des, out, ds, in, inlen); EVP_DecryptFinal(ctx_des, out + ds, ps); Now, with openssl-0.9.8 everything is fine, EVP_DecryptFinal returns 1 indicating that the padding was OK. With openssl-0.9.8d, I get an error from EVP_DecryptFinal, (which is indicating a padding error, isn't it?) Any idea of what is going on? Has support for that padding scheme been discontinued in the middle of the 0.9.8 series? Am I missing something that should be obvious? Thanks for any insight... Stefan Neis __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1504] Padding bug in 0.9.8d (Solaris 9, Sparc)
Hi, An additional bit of information: The behaviour doesn't seem to be platform specific, I can reproduce it on Intel(or rather AMD) under Linux as well (same gcc version (3.4.4) though). Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1504] Padding bug in 0.9.8d (Solaris 9, Sparc)
Stephen Henson via RT:
(snipp)
I'm totally confused by a difference I'm observing
between openssl-0.9.8 and openssl-0.9.8d, both
compiled on the same solaris box with the same
compiler installation (gcc-3.4.4), both passing
make test.
(snipp)
Can you include a complete program that reproduces this error?
(snipp)
Okay, here it is - sorry for the longish cipher text included in
the code, but I'm not confident enough in it's length being
irrelevant to trim it down.
#include stdio.h
#include openssl/err.h
#include openssl/x509.h
typedef unsigned char BYTE;
int main()
{
BYTE key[16]={0x60, 0xC1, 0xE1, 0x8E, 0x30, 0x6E, 0x33, 0x8A,
0xAF, 0xC1, 0x36, 0x55, 0xB8, 0x8A, 0x02, 0x43};
BYTE in[] = {0x83, 0xE1, 0xD6, 0x89, 0x24, 0x71, 0xB2, 0x42,
0x07, 0x13, 0x57, 0x80, 0x80, 0x29, 0xFC, 0xFE,
0xF5, 0xEC, 0xE9, 0xAB, 0x20, 0x8E, 0x8B, 0x5E,
0x5F, 0x22, 0x07, 0xD3, 0x09, 0xBB, 0x1F, 0x19,
0xAD, 0x76, 0x13, 0x26, 0x7B, 0x08, 0x10, 0xFC,
0x79, 0x01, 0x5D, 0xDE, 0x70, 0xE1, 0xCD, 0xB0,
0xE4, 0xC0, 0x80, 0xFB, 0xC1, 0x76, 0x9E, 0x81,
0x22, 0x44, 0xAA, 0x59, 0x17, 0x90, 0x8F, 0x56,
0x7F, 0x2A, 0x43, 0x28, 0x3B, 0xEB, 0xCD, 0xCE,
0xFB, 0x26, 0xD1, 0x5E, 0x2E, 0x4F, 0x67, 0x53,
0xFB, 0x1F, 0x6C, 0xBB, 0xA2, 0x80, 0xD6, 0x6D,
0x90, 0xB5, 0x7C, 0xC9, 0x5E, 0x00, 0x58, 0xE5,
0x45, 0xE7, 0x91, 0x28, 0xDA, 0xE8, 0x16, 0xC7,
0xEC, 0xB6, 0x98, 0x3B, 0x79, 0xBE, 0xB8, 0xB6,
0xF2, 0xA1, 0x3D, 0xD8, 0xAA, 0xE1, 0x15, 0xAD,
0x1B, 0xBD, 0x06, 0x8A, 0xF1, 0x03, 0x13, 0xE1,
0x6C, 0x97, 0x86, 0xC9, 0xC5, 0x68, 0x30, 0x0A,
0x5D, 0x13, 0x13, 0xAF, 0xDA, 0xC2, 0x5F, 0xE1,
0x69, 0x45, 0xF4, 0x1D, 0x52, 0x75, 0xE5, 0x38,
0xB4, 0xB9, 0x5D, 0xEC, 0xA4, 0x72, 0xDC, 0x8E,
0x90, 0x06, 0xC1, 0xA8, 0xBA, 0xA8, 0xDE, 0x7E,
0x0C, 0x61, 0x7F, 0x97, 0xE4, 0x77, 0xF3, 0xC3,
0x04, 0xBF, 0xD9, 0x20, 0xD7, 0xD4, 0xF9, 0xE6,
0x10, 0xC3, 0x23, 0x7D, 0xDE, 0x6F, 0x99, 0x79,
0x2D, 0x32, 0xB3, 0x90, 0xA5, 0x02, 0xA1, 0x75,
0x1C, 0xC2, 0x3C, 0xDB, 0x6C, 0x80, 0x4B, 0x2D,
0x16, 0xB4, 0xB3, 0x5F, 0xCB, 0xA1, 0xD0, 0x84,
0x91, 0xE9, 0x21, 0xA9, 0xB8, 0x57, 0x82, 0xD4,
0xCC, 0xB0, 0x8B, 0x99, 0x68, 0x57, 0x63, 0x66,
0x57, 0xBA, 0xEE, 0x7D, 0x42, 0x1B, 0x75, 0x90,
0x14, 0xA2, 0xAF, 0xF2, 0xDC, 0x68, 0x44, 0x9C,
0x7E, 0xEB, 0x7A, 0x94, 0xF3, 0x35, 0x9C, 0x67,
0xE9, 0xAA, 0xF4, 0xE6, 0xF4, 0x33, 0xF0, 0x0E};
EVP_CIPHER_CTX ctx_des;
int ds, ps, ret;
int inlen = sizeof(in);
BYTE *out;
printf(Decrypt message with length %d\n, inlen);
ERR_load_crypto_strings();
EVP_DecryptInit(ctx_des, EVP_des_ede_cbc(), key, NULL);
out = (BYTE*)malloc(inlen + EVP_CIPHER_block_size(EVP_des_ede_cbc()));
EVP_DecryptUpdate(ctx_des, out, ds, in, inlen);
ret = EVP_DecryptFinal(ctx_des, out + ds, ps);
printf(Decrypt: %d (%d, %d)\n, ret, ds, ps);
ERR_print_errors_fp(stderr);
}
Here's my relevant shell output, showing both
compilations and their result:
bash-2.05$ /home/SunOS/bin/openssl version
OpenSSL 0.9.8d 28 Sep 2006
bash-2.05$ g++ -o openssl_test -I/home/SunOS/include openssl_test.cpp
/home/SunOS/lib/libcrypto.a -lsocket -lnsl
bash-2.05$ ./openssl_test
Decrypt message with length 264
Decrypt: 0 (256, 0)
2162:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad
decrypt:evp_enc.c:461:
bash-2.05$ /opt/gcc/openssl/bin/openssl version
OpenSSL 0.9.8 05 Jul 2005
bash-2.05$ g++ -o openssl_test -I/opt/gcc/openssl/include openssl_test.cpp
/opt/gcc/openssl/lib/libcrypto.a -lsocket -lnsl
bash-2.05$ ./openssl_test
Decrypt message with length 264
Decrypt: 1 (256, 8)
Regards,
Stefan
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1493] -march=ultrasparc doesn't work on Solaris 9
Hi, -mcpu wasn't deprecated on SPARC. I think it was only deprecated on i386. Seems that some platforms support -mcpu and others -march, ugh. I've reverted the sparc changes to the Configure script. BTW, you might want to double check (in general), whether you want to use -march, -mtune, or -mcpu flags. It's apparently not only platform/version specific, which of the three flags are supported, but especially the meaning of -mcpu seems to depend on the platform as well. E.g. on Intel, -mcpu seems to behave like Sparc's -mtune option (optimize e.g. scheduling for that CPU but don't use CPU specific commands) while Sparc's -mcpu option behaves like Intel's -march option (do use CPU specific commands). BTW, at least for gcc-3.3.5, the info file does not state anything about -mcpu being deprecated on Intel, on the contrary, -mcpu and -march even have different meaning. What is mentioned as deprecated, though, is the use of -m386, -mpentium and the like which should be replaced by -mcpu=i386, -mcpu=pentium and the like. Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
Hi, I tried to compile OpenSSL using MinGW on Linux, but I could not do this. I've tried to modify configurations, converting ms/mingw.bat to ms/mingw.sh, removing the translation of / into \, and more... Before I making too much modifications, Have anyone succeeded in doing so? The easier way probably is to modify the Configure script and then go the standard Unix route of compiling. I know I've found (and used) patches for doing this, googling for something like mingw Configure OpenSSL Since that was more than 6 months ago, it might even have been added into current distributions and you just need to figure out the right parameter for Configure (searching it for mingw to see what variants it offers might turn up something). Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: OPENSSL_gmtime on platforms that don't have a safe gmtime function
Hi, why not use mutexes to wrap the gmtime and memcpy, like other places in the library? Because it is either needless or insufficient. (snipp) On platforms where thread-specific data is not used, the mutexes would not prevent other code (not part of OpenSSL) from calling these functions in-between when OpenSSL calls them and when the returned data can be used or copied. Well, while it is still insufficient, mutexes would allow a user calling OpenSSL functions from multiple threads to do so without having to worry about all the internals, like do function a() and b() both use gmtime internally, so a common mutex around those two function calls is needed? Not to mention that in a cross-platform application it's going to be needed on a few platforms only, while on most it will work without them. Ensures interesting testing and debugging sessions, IMO. Of course, if the user is calling gmtime himself, he still needs to know such stuff, but that might be less common than calling two openssl functions that end up calling gmtime. Also, you could add a warning in such case that any multi-threaded application needs to wrap their gmtime calls with such and such mutex. OTOH, if you have two or more libraries taking this approach, each using a gmtime wrapper with its own mutex, that's possibly going to be more confusing than helpful. Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Implmentation for VC++6.0
Hi, I´m developing an application that uses OpenSSL. It´s working great, but it's an activeX componet so it has 3 dependencies, I really need a Visual Studio Project with the OpenSSL to compile them with my current proyect. I don´t want a DLL with 3 dependencies, I just want an Individual oneI will be very happy if someone could help me. Thanks to all. I completely fail to see the problem... Why not just compile OpenSSL as a static lib and link with that? Why do you think you need a project file? Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] make AES-cfb128-encrypt faster by uglifying it
Hi,
3. From my experience with gcc on powerpc, gcc handles
large unaligned load/stores correctly by splitting
them (sometimes unnecessary), but the code remains
correct and in working order.
Just as a counter example, on SUN, unaligned load stores
just crash. Reliably and every time, no matter what compiler
you use. Just try compiling and running somthing like
int f(){char a[5]; return htonl((int*)(a+1));}
on such a machine if you don't believe it.
Regards,
Stefan
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: HP-UX Poblem
Hi, I've just tried compiling OpenSSL-0.9.8a for HPPA64 architecture (using gcc-4.1) and 'make test' ends with ... ecb idea ok cbc idea ok cfb64 idea ok ../util/shlib_wrap.sh ./shatest *** Termination signal 139 Stop. *** Error exit code 1 Stop. Any known remedy? E.g. compiling specific files with lower optimiation level? Hm, replacing -O3 by -O0 for that platform in Configure and rerunning Configure ng with an no-asm and rebuilding every- thing didn't have any success either. Any suggestions? Has using a different compiler been suggested already? Any suggestions for the newest gcc that's known to work? 3.4.5? I'm using one of HP's Testdrive machines for building, so I suppose building several compilers wouldn't be appreciated too much, especially since the 4.1.0 that's causing the problem has been installed on our request that we need a compiler for the 64-bit flavour ... (though, luckily, the version was their choice, not ours, so I don't feel completely stupid. ;-) ) might it be possible to tusc trace that specific test? Sorry? I didn't quite understand that one. Could you explain in more detail what you have in mind? Anyway, I've tried to have a look with gdb, but apparently that was a 32-bit version only and didn't give anything meaningful. Also Peter Waltenberg suggested: make sure you got Configure right first time. If you configure for the wrong wordlength it won't get fixed by make clean. Yes, that's a lesson I learned on AIX half a year ago... ;-) rm the directory and untar from scratch is the most reliable fix, I did. Several times, actually, even when just changing from -O3 to -O0. Thanks, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: HP-UX Poblem
Hi, so I didn't really think of using HP's compiler. Well, using HP's compiler, I get an OpenSSL version which does successfully pass the make test command... Looks more and more like a bug in gcc-4.1 Portable code is a chore ain't it :) It could be worse, you could be trying to include Windows at the same time. It does work on Windows, Solaris, AIX and Linux already... ;-) I find that by compiling netperf with gcc, HP C, xlC, MS C etc... I find far more issues in my own code than in the compilers. And many of those issues are ticking timebombs I need to take care of anyway. Yes, I know. Still ... Of course that is C, not C++, so things are rather more stable there but still... Exactly. If you run into problems, there is the [EMAIL PROTECTED] mailing list that is for folks using the HP C++ compilers. C stuff gets discussed there too. Thanks. Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] printf size_t support.
Hi, Is the patch tested on windows ? z modifier - I'm not sure that this is portable. if I remember correctly windows doesn't support this modifier (at least I was told this as we discussed this for another project) I'm not exactly sure, but I believe it's an extension of glibc (or maybe of C99 ?). At least, it doesn't seem to be supported by older Unix systems either, e.g. it's apparently not supported by Solaris 7. Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]
Hi, If you simply use the -Bsymbolic flag when building libA, doesn't that solve the problem as well? And in a more portable way, since vrsioned symbols don't exist on many platforms? AFAIK, the idea of the flag is that the library doesn't automatically doesn't resolve its symbols against the global symbols from the main program or other libs loaded, but only against those libs that it was linked against. No it doesn't. In fact, -Bsymbolic really should be avoided since it opens alot more problems that it solves. OK, I'm lost... What does it actually do? It sure was the only way to get my PKCS#11 module to actually link against the MD5 routines in the [static] library it used instead of having it reuse the (incompatible) symbols with the same name contained in the Nescape/Mozilla binary. And my conclusion from that observation was that unless you do know enough details of all the binaries that will ever use your shared object in advance, you want to link your shared object with -Bsymbolic ... Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]
Hi, Then when the dynamic linker looks for a symbol, it looks at it by name. It will go over all objects to see if it exists in it. It will use the symbol from the first library it finds it in. This means, that a symbol that libA requires, and _should_ get from libssl.so.0.9.7, can also exist in libssl.so.0.9.8, and will most likely be using that. If libssl.so.0.9.8 has a different ABI, this breaks. The way to make sure that libA gets the symbol with the right ABI, is to have all symbols have a unique name. This can be done with symbol versioning. It then gets named symbol@@version. The runtime linker adds references to the versioned symbol, and dynamic linker then looks for the versioned symbols. If you simply use the -Bsymbolic flag when building libA, doesn't that solve the problem as well? And in a more portable way, since vrsioned symbols don't exist on many platforms? AFAIK, the idea of the flag is that the library doesn't automatically doesn't resolve its symbols against the global symbols from the main program or other libs loaded, but only against those libs that it was linked against. Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1230] static(no-shared) build for VC-32 have wrong codegeneration option
** Reply to note from Konstantin Sharenkov via RT [EMAIL PROTECTED] Wed, 26 Oct 2005 11:36:41 +0200 (METDST) Hi, but nt.mak contins line CFLAG= /MD /Ox /O2 /Ob2 /W3 /WX /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -D_CRT_SECURE_NO_DEPRECATE -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM /Fdout32 -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_KRB5 The first option is /MD - Multithreaded DLL code generation But for static library option should be /MT Multithreaded code generation Not really, IMHO. Note that /MD or /MT is just about whether you want your (static) library to be used with the static C library or with the DLL. There are a number of reasons why using the DLL version of the C library is preferable, most significantly it's more widely usable (using the static C library typically implies that you cannot load DLLs without a high probability of erratic runtime behaviour and crashes), so if you are statically linking openssl lib against _several_ applications and can't be sure that none of them will _ever_ use _any_ DLL in advance, compiling with /MD is the better way to go. If you do network installations that are going to be used by several people, that's even more true. In short /MD is slightly more flexible and the risk that MS is actually breaking msvcrt.dll in an update has come quite close to 0 in the past 7 or so years. With /MD I have a typical problem (for mixed code generation) during linking my application. With /MT everything is ok. Over here, for _my_ application, everything is ok with /MD and /MT would be causing problems, so it's obviously impossible to do it in a way that makes everyone happy - unless, of course, you add even more variants to the makefile, which OTOH would cause additional confusion... Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: AIX 64 Bit gcc
Hi again, Is there a reason why openssl-0.9.8 doesn't support building a 64-bit version with gcc on AIX machines (nor does openssl-0.9.8a, AFAICS)? You have to keep in mind that some targets are community supported, that includes config lines, testing and eventual adaptations. None of OpenSSL developers have access to AIX, which is why you can't expect new AIX targets popping up nor have any sensible answer to questions like why not. Sorry, my wording was a bit unlucky. I just somehow got the impression that documentation claimed somewhere there _is_ support for 64-bit compilation on AIX with gcc (can't seem to find the part the induced that thought any more, though, I might have mixed up gcc+AIX on the one hand and xlc+AIX64 on the other while reading or something), so I was thinking there might be a problem with that configuration which caused removal of it (after all, if it doesn't work and you don't have access to a machine to test and fix it, that's sometimes the best option...), so essentially I wanted to know if there's a known problem with it and I was just lucky to not have encountered it (yet) or if it really is just a new configuration. Thanks for the good work, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
AIX 64 Bit gcc
Hi, [ Sorry this is slightly outdated (I'm just back from three weeks of holiday and really wanted to send it before leaving ...) ] Is there a reason why openssl-0.9.8 doesn't support building a 64-bit version with gcc on AIX machines (nor does openssl-0.9.8a, AFAICS)? The following patch adds an entry for this configuration in configure, the resulting binaries successfully pass make test and seem to work at least in my application: diff -r -u openssl-0.9.8/Configure openssl-0.9.8.patched/Configure --- openssl-0.9.8/Configure 2005-07-05 01:24:11.0 +0200 +++ openssl-0.9.8.patched/Configure 2005-09-08 18:04:54.0 +0200 @@ -404,6 +404,7 @@ IBM's AIX. aix3-cc, cc:-O -DB_ENDIAN -qmaxmem=16384::(unknown):AIX::BN_LLONG RC4_CHAR:::, aix-gcc, gcc:-O -DB_ENDIAN::-D_THREAD_SAFE:AIX::BN_LLONG RC4_CHAR::aix_ppc32.o::dlfcn:, +aix64-gcc, gcc:-O -DB_ENDIAN::-D_THREAD_SAFE:AIX::SIXTY_FOUR_BIT_LONG RC4_CHAR::aix_ppc64.o::dlfcn::-X64, # Below targets assume AIX 5. Idea is to effectively disregard $OBJECT_MODE # at build time. $OBJECT_MODE is respected at ./config stage! aix-cc, cc:-q32 -O -DB_ENDIAN -qmaxmem=16384::-qthreaded:AIX::BN_LLONG RC4_CHAR::aix_ppc32.o::dlfcn:aix-shared::-q32:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)::-X 32, HTH, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
OpenSSL-0.9.8(a) on OS/2
Hi, OpenSSL-0.9.8a fails to link for me on OS/2, a simple patch ensuring the correct compilation options (patch) diff -r -u openssl-0.9.8/util/pl/OS2-EMX.pl openssl-0.9.8.patched/util/pl/OS2-EMX.pl --- openssl-0.9.8/util/pl/OS2-EMX.pl2003-11-28 15:51:29.0 +0100 +++ openssl-0.9.8.patched/util/pl/OS2-EMX.pl2005-08-15 19:01:44.0 +0200 @@ -68,6 +68,7 @@ $sha1_asm_src=crypto/sha/asm/s1-os2.asm; $rmd160_asm_obj=crypto/ripemd/asm/rm-os2$obj; $rmd160_asm_src=crypto/ripemd/asm/rm-os2.asm; +$cflags.= -DBN_ASM -DMD5_ASM -DSHA1_ASM -DOPENSSL_BN_ASM_PART_WORDS; } if ($shlib) - (end of patch) - fixes that problem for me. That very same issue had already been reported in January by Brian Havard (for 0.9.7e?), see http://www.mail-archive.com/openssl-dev@openssl.org/msg18635.html Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
