crypto and ssl modules under OSX

[Sean Hinde]

On 3 Dec 2004, at 09:01, Bjorn Gustavsson wrote:

> Sean Hinde <sean.hinde@REDACTED> writes:
>
>> Hi Bjorn,
>>
>> I hope your change gets rid of the undocumented -lbundle1.o and
>> reverts to using the mechanism in the README - namely -bundle, and
>> using the cc program to link rather than ld
>
> No, sorry.
>
> Our Makefiles must work on all platforms (including other Unixes,
> Windows, VxWorks and other embedded system). Currently, the Makefiles
> use the C compiler for compiling and ld for linking.
>
> Starting to use the C compiler for linking will probably not work
> for some platform, so that is not an option.
>
> The best way to solve the problem would of course be to choose whether 
> to use
> gcc or ld for linking on a platform-by-platform basis, but that would
> require changes to configure.in and many Makefiles in source code and 
> a lot of
> time for testing.

I don't understand this - there is already an explicit rule done in 
configure.in for darwin. You already have a DED_LD substitution for 
precisely this purpose. The patch is trivial:

--- configure.in.orig   Fri Dec  3 10:17:19 2004
+++ configure.in        Fri Dec  3 10:18:13 2004
@@ -1162,8 +1162,9 @@
                 darwin*)
                         # Mach-O linker: a shared lib and a loadable
                         # object file is not the same thing.
-                       DED_LDFLAGS="-bundle -flat_namespace -undefined 
suppress -lbundle1.o"
+                       DED_LDFLAGS="-bundle -flat_namespace -undefined 
suppress"
                         DED_CFLAGS="$DED_CFLAGS -fno-common"
+                        DED_LD="$CC"
                 ;;
                 *)
                         # assume GNU linker and ELF

So long as DED_LD is used for linking the various drivers then nothing 
will be broken - everything else will use the default value of ld. I 
provided a complete patch set sometime ago to do just this.

Equally I don't get the reluctance to tidy up or make any changes to 
the build procedure. You have a set of Officially Supported platforms, 
which you presumably can and do test every night in a fully automated 
way.

Unsupported platforms are just that - if you break the build for some 
ancient version of some weird and wonderful UNIX toolchain as part of a 
tidy up then the community will provide patches if they care enough. If 
it becomes broken and no-one notices then that suggests that no-one is 
using that platform anyway.

I see this in action most releases - the *BSD crew submit patches, and 
Redhat Latest always seems to break something. No-one minds too much, 
or if they do they either provide a fix it or use a supported platform.

You guys should be able to make more use of the open source community, 
and support of "non-supported" platforms would seem to be a good start.

<end_soapbox/>

Sean