From ingela@REDACTED Thu Sep 4 08:34:28 2008 From: ingela@REDACTED (Ingela Anderton Andin) Date: Thu, 04 Sep 2008 08:34:28 +0200 Subject: [erlang-patches] erl_script_alias enhancement proposal In-Reply-To: <48B77FA9.6090709@charpi.net> References: <48B77FA9.6090709@charpi.net> Message-ID: <48BF8174.2020101@erix.ericsson.se> Hi! Nicolas Charpentier wrote: > Hi, > I don't know if it's the correct mailing list to send such patch. Let > me know if I'm doing 'bad things'. > No you are not doing anything wrong. It is a good place to send such a suggestion. > > * Purpose of the evolution. > > Right now if you have a httpd configuration containing > {erl_script_alias, "/my_dir", [ mod1, mod2]}, you'll be able to > execute erlang module hitting urls like > http://myhost/my_dir/mod1:any_function and > http://myhost/my_dir/mod2:anyfunction > > I'd like to be able to omit the module and the function name in the > url. (put http://myhost/my_dir or http://myhost/my_dir/ in my broswer) > and get some erlang code executed. > > > * Enhancement proposal > > Add the possibiity to configure httpd with something like > {erl_script_alias, {"my_dir",{{Module,Function}, Authorized_modules}}}, > Where Module:Function will be the function called for the url "/my_dir" > > Alas we are somewhat short staffed in compared to the current workload so we have not had time to really look at your proposal. But I have put it on the todo-list for inets and at first glance I do not see any problems with it but it is not on top of the priority list, hopefully it can make it for the R12B-5 ... but no promises. Regards Ingela Erlang/OTP - Ericsson From nem@REDACTED Wed Sep 10 13:45:24 2008 From: nem@REDACTED (Geoff Cant) Date: Wed, 10 Sep 2008 13:45:24 +0200 Subject: [erlang-patches] OS X fixes (HiPE, ddll unload) Message-ID: Hi all, I wrote a couple of patches last night that improves Erlang OS X support. * http://github.com/mfoemmel/erlang-otp/commit/cf55be9b6dfcdbe8600decfee02d233e91cd88c2 This first patch is to replace the custom NSLinkModule machinery used for loading libraries at runtime. While the old Apple TechNote TN2701 recommends you use NSLinkModule when porting unix applications, it was mainly intended for OS X 10.2. Since OS X 10.3, the dlopen/dlsym/dlclose/dlerror/dladdr functions are supported and preferred. In the patch I've simply removed the HAVE_MACH_O_DYLD_H ifdefs and special cases. The OS X code is now the same as other platforms with HAVE_DLOPEN support. * http://github.com/mfoemmel/erlang-otp/commit/8eb2f8c0b19bec023b8d1e8446b58c30b53c3c44 Since OS X 10.5.3 it hasn't been possible to compile Erlang/OTP with hipe enabled due to problems with hipe_signal_init dumping core with a SIGBUS while trying to patch sigaction (http://www.erlang.org/pipermail/erlang-bugs/2008-May/000813.html). The cause of this appears to be mach_override causing a SIGBUS for reasons I don't understand. In the patch I've altered the hipe_signal_init code to use the same _sigaction wrapping mechanism as linux and solaris (saving the old _sigaction via dlsym(RTLD_NEXT, "sigaction") and then overwriting that address with a pointer to hipe's my_sigaction wrapper). As far as I can tell, this should work the same way as other platforms and removes the dependency on mach_override. As this is my first foray into the guts of the emulator, I don't know how reliable these patches are. From my own testing, crypto (and crypto_drv) seemed to work fine so I think the erl_ddll patch works, and with the HiPE patch I could actually build erlang (a big improvement), start a node, hipe compile and use the lists module in a simple test - so I think that roughly works too. Are there some test suites I could run to verify that these patches do the right thing? If the patches are OK, what do I need to do to get them included in a future OTP release? Cheers, -- Geoff From mikpe@REDACTED Wed Sep 10 14:07:42 2008 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 10 Sep 2008 14:07:42 +0200 Subject: [erlang-patches] OS X fixes (HiPE, ddll unload) In-Reply-To: References: Message-ID: <18631.47246.64344.196455@harpo.it.uu.se> Geoff Cant writes: > * http://github.com/mfoemmel/erlang-otp/commit/8eb2f8c0b19bec023b8d1e8446b58c30b53c3c44 > > Since OS X 10.5.3 it hasn't been possible to compile Erlang/OTP with > hipe enabled due to problems with hipe_signal_init dumping core with a > SIGBUS while trying to patch sigaction > (http://www.erlang.org/pipermail/erlang-bugs/2008-May/000813.html). The > cause of this appears to be mach_override causing a SIGBUS for reasons I > don't understand. > > In the patch I've altered the hipe_signal_init code to use the same > _sigaction wrapping mechanism as linux and solaris (saving the old > _sigaction via dlsym(RTLD_NEXT, "sigaction") and then overwriting that > address with a pointer to hipe's my_sigaction wrapper). As far as I can > tell, this should work the same way as other platforms and removes the > dependency on mach_override. > > As this is my first foray into the guts of the emulator, I don't know > how reliable these patches are. From my own testing, crypto (and > crypto_drv) seemed to work fine so I think the erl_ddll patch works, and > with the HiPE patch I could actually build erlang (a big improvement), > start a node, hipe compile and use the lists module in a simple test - > so I think that roughly works too. > > Are there some test suites I could run to verify that these patches do > the right thing? If the patches are OK, what do I need to do to get them > included in a future OTP release? First step is to publish the changesets as actual patches, i.e., text files people can review and 'patch' can apply to an unpacked vanilla R12B source tarball. I did look around in that github thing, but couldn't immediately find a way to export the changeset as a patch. At least one other web git interface, the one at git.kernel.org, does allow that. As far as getting OSX changes to hipe_x86_signal.c in upstream, I'd say the chances are good. /Mikael From nem@REDACTED Wed Sep 10 16:27:50 2008 From: nem@REDACTED (Geoff Cant) Date: Wed, 10 Sep 2008 16:27:50 +0200 Subject: [erlang-patches] OS X fixes (HiPE, ddll unload) In-Reply-To: <18631.47246.64344.196455@harpo.it.uu.se> (Mikael Pettersson's message of "Wed, 10 Sep 2008 14:07:42 +0200") References: <18631.47246.64344.196455@harpo.it.uu.se> Message-ID: Mikael Pettersson writes: > > First step is to publish the changesets as actual patches, > i.e., text files people can review and 'patch' can apply to > an unpacked vanilla R12B source tarball. > > I did look around in that github thing, but couldn't immediately > find a way to export the changeset as a patch. At least one other > web git interface, the one at git.kernel.org, does allow that. > > As far as getting OSX changes to hipe_x86_signal.c in upstream, > I'd say the chances are good. > > /Mikael Ah, my apologies - I've attached the actual patch files here. They're prepared with git format-patch, so they should apply from within the root of the R12B-4 checkout with patch -p1. (On further investigation github has patch download, but with no actual links to said functionality) (http://github.com/mfoemmel/erlang-otp/commit/cf55be9b6dfcdbe8600decfee02d233e91cd88c2.diff) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Altering-Mac-OS-X-ddll-code-to-use-dlopen-rather-tha.patch Type: text/x-patch Size: 3625 bytes Desc: not available URL: -------------- next part -------------- (http://github.com/mfoemmel/erlang-otp/commit/8eb2f8c0b19bec023b8d1e8446b58c30b53c3c44.diff) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fixing-HiPE-bus-errors-on-Mac-OS-X-10.5.3-removes.patch Type: text/x-patch Size: 2965 bytes Desc: not available URL: -------------- next part -------------- Cheers, -- Geoff From kenji.rikitake@REDACTED Sun Sep 14 03:41:11 2008 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Sun, 14 Sep 2008 10:41:11 +0900 Subject: [erlang-patches] leap-second-enabled FreeBSD doesn't work right with R12B4 erts/emulator/beam/erl_time_sup.c; correction patch included Message-ID: <20080914014111.GA7026@k2r.org> A patch to correct erlang:universaltime_to_localtime/1 for FreeBSD running leap-second-enabled timezone by Kenji Rikitake 14-SEP-2008 * Summary This patch fixes the time calculation problem of FreeBSD 6.x and 7.x, which has the internal leap-second correction enabled. This patch is tested with Erlang/OTP R12B-4 source distribution. * Symptom Without this patch, erlang:localtime_to_universaltime/1 and erlang:universaltime_to_localtime/1 are not symmetric and will break calendar:local_time_to_universal_time_dst_1/1 and httpd_util:rfc1123_date/1 * Example of symptom: (under where local time is GMT + 9 hours) 1> erlang:localtime_to_universaltime({{2008,9,1},{12,0,0}}). {{2008,9,1},{3,0,0}} 2> erlang:universaltime_to_localtime({{2008,9,1},{3,0,0}}). {{2008,9,1},{11,59,37}} (Note that as of September 1, 2008, TAI - UTC = 33 seconds. UNIX time_t with TAI correction is 10 seconds ahead of UTC. So the 23-second difference occurs when the leap-second correction is NOT performed, as in the C function of univ_to_local() in erts/emulator/beam/erl_time_sup.c) * Workaround in this patch This patch changes the operation of erlang:universaltime_to_localtime/1 so that the "universaltime" is handled properly with leap-year correction. (Note: OS time_t is in TAI) See FreeBSD man time2posix(3) and /usr/src/lib/libc/stdtime/localtime.c for the further details. This patch will NOT affect a FreeBSD machine without leap-year correction; posix2time() will do nothing in such a situation. (NOT tested though) * Caveats, TODO and suggestions There is no portable way to do this among UNIX-derived OSes HAVE_POSIX2TIME should be set by configure A Linux patch for leap-second supported systems is highly desired (I found posix2time() is also available on Linux, but I'm not sure) Should I rather do this using timegm(3) and throw away the rather naive computation algorithm in univ_to_local()? (Note that this is not necessarily portable either) * How to apply this patch Apply this at Erlang R12B4 source tree's directory under: erts/emulator/beam --- erl_time_sup.c.FCS 2008-04-07 22:57:50.000000000 +0900 +++ erl_time_sup.c 2008-09-14 09:56:10.000000000 +0900 @@ -71,6 +71,10 @@ ** */ +/* FreeBSD internal leap year correction function */ +/* define this for FreeBSD 6.x and 7.x */ +#define HAVE_POSIX2TIME + #ifdef HAVE_CONFIG_H # include "config.h" #endif @@ -686,6 +690,18 @@ the_clock = *second + 60 * (*minute + 60 * (*hour + 24 * gregday(*year, *month, *day))); +#ifdef HAVE_POSIX2TIME + /* + * leap-second correction performed + * if system is configured so; + * do nothing if not + * See FreeBSD 6.x and 7.x + * /usr/src/lib/libc/stdtime/localtime.c + * for the details + */ + the_clock = posix2time(the_clock); +#endif + #ifdef HAVE_LOCALTIME_R localtime_r(&the_clock, (tm = &tmbuf)); #else From kenji.rikitake@REDACTED Sun Sep 14 05:12:10 2008 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Sun, 14 Sep 2008 12:12:10 +0900 Subject: [erlang-patches] [erlang-bugs] leap-second-enabled FreeBSD doesn't work right with R12B4 erts/emulator/beam/erl_time_sup.c; correction patch included In-Reply-To: References: <20080914014111.GA7026@k2r.org> Message-ID: <20080914031210.GA9162@k2r.org> In the message dated Sat, Sep 13, 2008 at 08:03:30PM -0700, Matthew Dempsky writes: > > Should I rather do this using timegm(3) and throw away > > the rather naive computation algorithm in univ_to_local()? > > (Note that this is not necessarily portable either) > > mktime(3) is defined by POSIX. mktime() certainly is, but timegm() isn't, AFAIK. An example implementation in the following URL will not be thread-safe, due to the usage of getenv() and setenv(). http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/timegm.3.html BTW local_to_univ() in erl_time_sup.c uses mktime(), and I see no problem with it. Kenji Rikitake From kenji.rikitake@REDACTED Sun Sep 14 07:24:18 2008 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Sun, 14 Sep 2008 14:24:18 +0900 Subject: [erlang-patches] [erlang-bugs] leap-second-enabled FreeBSD doesn't work right with R12B4 erts/emulator/beam/erl_time_sup.c; correction patch included In-Reply-To: References: <20080914014111.GA7026@k2r.org> <20080914031210.GA9162@k2r.org> Message-ID: <20080914052418.GA10612@k2r.org> I also think using time2posix(3) and posix2time(3) will be a better way than timegm(), as Matthew describes. I've also found out that the following three functions calendar:now_to_datetime/1 calendar:now_to_universal_time/1 (equivalent to calendar:now_to_datetime/1) calendar:now_to_local_time/1 do not work in the leap-second-enabled environment, due to the fact that erlang:now/0 shows the internal clock value as is, with gettimeofday(2). The converted results of the functions include the offset of ((TAI-UTC) - 10) seconds. Modifying erlang:now/0, defined as get_now() in erl_time_sup.c to include the offset of time2posix(3) is a possible solution, though I don't feel like to doing it because it will surely break the assumption of continuous monotonous increasing of erlang:now/0. Fixing only the calendar module functions by adding a time2posix(3) calculation routine written in C somewhere in the BEAM BIFs looks better to me, though I need to investigate further. Regards, Kenji Rikitake In the message dated Sat, Sep 13, 2008 at 09:00:20PM -0700, Matthew Dempsky writes: > On Sat, Sep 13, 2008 at 8:12 PM, Kenji Rikitake wrote: > > mktime() certainly is, but timegm() isn't, AFAIK. > > My mistake. I confused the local-vs-UTC time functions. > > time2posix(3) and posix2time(3) come from Olson's tz library, which > according to Wikipedia[1], is pretty widely used, so they seem like > they should be reasonably portable. Anywhere that doesn't have them > probably isn't leap second aware anyways. They're also present in > FreeBSD, NetBSD, and OpenBSD's cvs trees from over 10 years ago, so > they're hardly recent additions either. > > [1] http://en.wikipedia.org/wiki/Zoneinfo#Use_in_software_systems > From kenji.rikitake@REDACTED Thu Sep 18 04:16:02 2008 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Thu, 18 Sep 2008 11:16:02 +0900 Subject: [erlang-patches] [erlang-bugs] leap-second-enabled FreeBSD doesn't work right with R12B4 erts/emulator/beam/erl_time_sup.c; correction patch included In-Reply-To: <20080914052418.GA10612@k2r.org> References: <20080914014111.GA7026@k2r.org> <20080914031210.GA9162@k2r.org> <20080914052418.GA10612@k2r.org> Message-ID: <20080918021602.GA6530@k2r.org> The attached patch includes an additional BIF erlang:now_utc/0 to solve the problem, as well as the previous fix for erlang:universaltime_to_localtime/1. Adding a BIF is surely experimental, but I think this is the easiest way to solve this issue. Changing erlang:now/0 semantics is quite risky. I'm still wondering if this is the best way to deal with the systems with leap-second-enabled wall clocks (and OSes). I'd appreciate if I can read any comment from Erlang/OTP Team on this issue. Regards, Kenji Rikitake In the message <20080914052418.GA10612@REDACTED> dated Sun, Sep 14, 2008 at 02:23:55PM +0900, Kenji Rikitake writes: > I've also found out that the following three functions > > calendar:now_to_datetime/1 > calendar:now_to_universal_time/1 (equivalent to calendar:now_to_datetime/1) > calendar:now_to_local_time/1 > > do not work in the leap-second-enabled environment, due to the fact that > erlang:now/0 shows the internal clock value as is, with gettimeofday(2). > The converted results of the functions include the offset of > ((TAI-UTC) - 10) > seconds. > > Modifying erlang:now/0, defined as get_now() in erl_time_sup.c to > include the offset of time2posix(3) is a possible solution, though I > don't feel like to doing it because it will surely break the assumption > of continuous monotonous increasing of erlang:now/0. > > Fixing only the calendar module functions by adding a time2posix(3) > calculation routine written in C somewhere in the BEAM BIFs looks better > to me, though I need to investigate further. -------------- next part -------------- A non-text attachment was scrubbed... Name: erl_now_utc.patch Type: text/x-diff Size: 6373 bytes Desc: not available URL: From saleyn@REDACTED Tue Sep 23 04:25:26 2008 From: saleyn@REDACTED (Serge Aleynikov) Date: Mon, 22 Sep 2008 22:25:26 -0400 Subject: [erlang-patches] Erlang shell patch for special keys Message-ID: <48D85396.4060907@gmail.com> Attached patch fixes handling of special keys in the Erlang shell. I tested this on Linux and Windows, though my primary concern was to get it working on Linux. Del - Delete char at current position ^-> - Move right one word ^<- - Move left one word ^W - kill a word ^U - kill a line Serge P.S. ^U is a merge of someone else's contrib - I saw this on the mailing list a couple of years ago, but don't recall who the author was... -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: erlin.erl.patch URL: From rvirding@REDACTED Tue Sep 23 13:52:35 2008 From: rvirding@REDACTED (Robert Virding) Date: Tue, 23 Sep 2008 13:52:35 +0200 Subject: [erlang-patches] Erlang shell patch for special keys In-Reply-To: <48D85396.4060907@gmail.com> References: <48D85396.4060907@gmail.com> Message-ID: <3dbc6d1c0809230452k417243e0j3af38271e6617ee6@mail.gmail.com> The ^U collides with the normal emacs use of ^U which I personally think is more useful. A philosophical point is whether to mix the emacs based commands we have today with more Windows inspired commands like ^<- and ^->? Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Wed Sep 24 15:41:13 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Wed, 24 Sep 2008 15:41:13 +0200 Subject: [erlang-patches] OS X fixes (HiPE, ddll unload) In-Reply-To: References: <18631.47246.64344.196455@harpo.it.uu.se> Message-ID: <6672d0160809240641s3bb80c34jba91dc83dbeaaa83@mail.gmail.com> > > > Ah, my apologies - I've attached the actual patch files here. They're > prepared with git format-patch, so they should apply from within the > root of the R12B-4 checkout with patch -p1. > > Thanks! I have applied your patches and built it on Mac OS 10.5.5 with --enable-hipe. It builds fine. I also compiled and run a small test program with the 'native' option. Mikael, is it OK to include the patch of hipe_x86_signal.c in the development branch for R12B-5? /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpe@REDACTED Wed Sep 24 16:08:29 2008 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 24 Sep 2008 16:08:29 +0200 Subject: [erlang-patches] OS X fixes (HiPE, ddll unload) In-Reply-To: <6672d0160809240641s3bb80c34jba91dc83dbeaaa83@mail.gmail.com> References: <18631.47246.64344.196455@harpo.it.uu.se> <6672d0160809240641s3bb80c34jba91dc83dbeaaa83@mail.gmail.com> Message-ID: <18650.18909.158458.773976@harpo.it.uu.se> Bjorn Gustavsson writes: > > > > > > Ah, my apologies - I've attached the actual patch files here. They're > > prepared with git format-patch, so they should apply from within the > > root of the R12B-4 checkout with patch -p1. > > > > > Thanks! > > I have applied your patches and built it on Mac OS 10.5.5 with > --enable-hipe. It builds fine. I also compiled > and run a small test program with the 'native' option. > > Mikael, is it OK to include the patch of hipe_x86_signal.c in the > development branch for R12B-5? Yes. Just commit it, I'll fix it up if it somehow breaks Linux or Solaris. /Mikael From dgud@REDACTED Wed Sep 24 16:45:20 2008 From: dgud@REDACTED (Dan Gudmundsson) Date: Wed, 24 Sep 2008 16:45:20 +0200 Subject: [erlang-patches] crypto man page error In-Reply-To: References: Message-ID: <48DA5280.6070803@erix.ericsson.se> I have updated and improved the example, hope that clears up the usage. /Dan Tim Fletcher wrote: > At the bottom of the crypto man page there is a section titled "DES in > CBC mode", which contains some example code which appears to be wrong. > "Key" and "IVec" are defined variables, but then the call to > crypto:des_cbc_encrypt/3 uses "K" and "I", which don't exist. > > Also, the parameter list in the call to crypto:des_cbc_decrypt/3 > doesn't contain any spaces, which is inconsistent (if not generally, > at least with the previous function call). > > More subjectively, I think the surrounding text has a few minor > grammatical errors and is generally a bit unclear, so it might be > worth checking the whole section through. > > Hope that helps. > > Tim > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-patches > From saleyn@REDACTED Fri Sep 26 14:29:57 2008 From: saleyn@REDACTED (Serge Aleynikov) Date: Fri, 26 Sep 2008 08:29:57 -0400 Subject: [erlang-patches] [erlang-questions] Redirect -remsh output In-Reply-To: <48DCB18D.7040709@gmail.com> References: <48DBEB16.9050903@gmail.com> <6c2563b20809251604v506fc646g1c31ec1b156b8686@mail.gmail.com> <48DC6456.1090402@gmail.com> <48DCB18D.7040709@gmail.com> Message-ID: <48DCD5C5.8040804@gmail.com> Actually there is a little bug in the patch which is fixed in the attachment. I would definitely vote for including this in the OTP distribution! Serge Mats Cronqvist wrote: > Serge Aleynikov wrote: >> I believe you are right, as tab-expansion works only on some standard >> modules (e.g. stdlib, kernel, etc) that are in the path on both nodes. >> >> So, adding the appropriate rpc:call/4 in both places should fix the >> issue. >> > from the shell; > io:setopts([{expand_fun,fun(B)->rpc:call(RemoteNode,edlin_expand,expand,[B]) > end}]). > > patch; > --- /home/masse/wrk/user_drv.erl 2008-09-26 11:54:04.000000000 +0200 > +++ /usr/lib/erlang/lib/kernel-2.12.3/src/user_drv.erl 2008-07-20 > 07:14:47.000000000 +0200 > @@ -113,11 +113,7 @@ > case init:get_argument(remsh) of > {ok,[[Node]]} -> > RShell = {list_to_atom(Node),shell,start,[]}, > - RGr = > - group:start(self(), RShell, > - [{expand_fun, > - > fun(B)->rpc:call(Node,edlin_expand,expand,[B] > - end)}]), > + RGr = group:start(self(), RShell), > {RGr,RShell}; > E when E =:= error ; E =:= {ok,[[]]} -> > {group:start(self(), Shell),Shell} > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: user_drv.erl.patch URL: From ignatios@REDACTED Fri Sep 26 14:40:31 2008 From: ignatios@REDACTED (Ignatios Souvatzis) Date: Fri, 26 Sep 2008 14:40:31 +0200 Subject: [erlang-patches] shared library avoidance code harmful on certain architectures Message-ID: <20080926124031.GC19155@cs.uni-bonn.de> Hi, erlang 12 fails to build on NetBSD/amd64. I was told to test the patches below. Basically - use of -lfoo will do the right thing on all (sane) systems, while the complicated stuff ended up using libfoo.a, which happened to work on NetBSD/i386, but fails on NetBSD/amd64 due to the created text relocations. should be able to give you more details. I'm only a user of Erlang, most of the time. Regards, -is Allow the system linker to use the shared library for dynamic modules. --- lib/crypto/c_src/Makefile.in.orig 2007-11-26 20:01:59.000000000 +0100 +++ lib/crypto/c_src/Makefile.in @@ -91,11 +91,7 @@ endif endif DYNAMIC_CRYPTO_LIB=@SSL_DYNAMIC_ONLY@ -ifeq ($(DYNAMIC_CRYPTO_LIB),yes) CRYPTO_LINK_LIB=-L$(SSL_LIBDIR) -lcrypto -else -CRYPTO_LINK_LIB=$(SSL_LIBDIR)/libcrypto.a -endif llow the system linker to use the shared library for dynamic modules. --- lib/ssl/c_src/Makefile.in.orig 2008-06-20 19:33:40.000000000 +0200 +++ lib/ssl/c_src/Makefile.in @@ -87,11 +87,7 @@ PORT_PROGRAM = $(BINDIR)/ssl_esock$(exe) SKIP_BUILDING_BINARIES := false # Try to be BC for R10 -ifeq ($(findstring @SSL_,@REDACTED@),@REDACTED) DYNAMIC_CRYPTO_LIB=yes -else -DYNAMIC_CRYPTO_LIB=@SSL_DYNAMIC_ONLY@ -endif ifeq ($(DYNAMIC_CRYPTO_LIB),yes)