[Pythonmac-SIG] Another build question: ssl?

[Dan Wolfe]

Looks like you're right... there's nothing in the man pages - ld, cc, 
or libtool - that indicates the current linker understands .so files... 
and given that my original objection based on seeing the search pattern 
go from .so, .dylib, .a to .dylib, .a, and the linker not understanding 
.so files, I'll change my position. : -)

I also did a closer review of your non configure file patches, I'd 
hazard a guess that while they're not needed for the ssl problem, we 
are going to need them as they appear to fix problems that we have yet 
to run into...

Have you considered that, by changing the configure file with "Darwin*) 
   SO=.dylib;;" you apparently no longer have to have the dylib blocks 
in unixcompiler.py find_library_file function? with SO = .dylib, it now 
executes the 'shared' block and ignores the 'dylib' block?  It probably 
be a good idea to remove this cruft...

And last, it doesn't look like your patch got uploaded to source forge 
- can you upload it up again?

Thanks for taking the time to convince me,

- Dan


On Friday, November 22, 2002, at 06:15  AM, Ronald Oussoren wrote:

>
> On Friday, Nov 22, 2002, at 08:09 Europe/Amsterdam, Dan Wolfe wrote:
>
>> On the other hand, if you can prove that it's compatible with 
>> everything out there, I'll gladly change my position.
>
> How about this:
>
> - I have a libpng.3.1.2.5.dylib in /opt/local/lib (libpng 1.2.5 
> installed using darwinports)
>
> $ cat t.c says:
> #include "png.h"
>
> int main(void)
> {
>      png_uint_32 v = png_access_version_number();
>
>      printf("Ping version %x\n", (int)v);
> }
> $ cp /opt/local/lib/libpng.3.1.2.5.dylib libpng.so
> $ cc -I /opt/local/include -L. -o t t.c -lpng -lz
> ld: can't locate file for: -lpng
> $ mv libpng.so libpng.dylib
> $ cc -I /opt/local/include -L. -o t t.c -lpng -lz
> $ ./t
> Ping version 27dd
> $
>
> This is on a MacOS 10.2.2 system with the most recent developer tools. 
> The example strongly suggests that the normal compiler and linker do 
> not recognize '.so' as the extension of shared libraries and therefore 
> just changing the shared library extension to '.dylib' should cause no 
> problems.
>
> Greetings,
> 	Ronald
>