From ATearse-Doyle@REDACTED Thu Sep 3 03:11:26 2009 From: ATearse-Doyle@REDACTED (Alex Tearse-Doyle) Date: Wed, 2 Sep 2009 18:11:26 -0700 Subject: FW: Message-ID: <4CF799094EE6B44892C698E247408837134BB50928@IRVEX002.corp.blizzard.net> This patch adds support for both hard and symbolic linking for Windows. Hard linking requires XP and an NTFS formatted drive. Symbolic linking on Windows requires either Windows Vista, Windows Server 2008, or Windows 7. The Windows API call for creating symbolic links is dynamically executed via LoadLibrary, which allows a single binary to handle both the OS supported and OS not-supported cases. For example calling file:make_symlink on a Windows XP will return {error, enotsup}, however the same call should work as expected on Windows Vista. All the file module functions are supported: make_link/2, make_sym_link/2, read_link/1, and read_link_info/1. The normal read_info/1 gives the number of links and uses the target of a symbolic link. On a side note, the file.erl man page, {error, exdev} isn't listed on file's man page as a valid return type for make_link, however the error is (correctly) returned when attempting to create a hard link to file on another volume (which should result in {error, exdev}). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: win_efile.diff Type: application/octet-stream Size: 5113 bytes Desc: win_efile.diff URL: From raimo+erlang-patches@REDACTED Thu Sep 3 09:28:32 2009 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Thu, 3 Sep 2009 09:28:32 +0200 Subject: [erlang-patches] Build system ignores LDFLAGS In-Reply-To: <2da21fe50908171403n58809a00ob0eb59d5866a3007@mail.gmail.com> References: <2da21fe50908161305n6b3ce3cam3283ed47fadf91e6@mail.gmail.com> <2da21fe50908171403n58809a00ob0eb59d5866a3007@mail.gmail.com> Message-ID: <20090903072832.GA19850@erix.ericsson.se> On Mon, Aug 17, 2009 at 11:03:21PM +0200, Davide Pesavento wrote: > On Mon, Apr 20, 2009 at 14:30, Raimo > Niskanen wrote: > > On Fri, Apr 17, 2009 at 11:34:49PM +0200, Davide Pesavento wrote: > >> On Sat, Apr 4, 2009 at 13:05, Davide Pesavento wrote: > >> > On Tue, Mar 31, 2009 at 22:13, Davide Pesavento wrote: > >> >> Hello, > >> >> > >> >> Erlang's build system seems to ignore custom LDFLAGS. This is the QA > >> >> warning shown by Portage (Gentoo Linux's package manager) after > >> >> building R12B-5 with LDFLAGS="-Wl,-O1 -Wl,--as-needed > >> >> -Wl,--hash-style=gnu" > >> >> > >> >> QA Notice: Files built without respecting LDFLAGS have been detected > >> >> ?Please include the following list of files in your report: > >> >> /usr/lib64/erlang/lib/runtime_tools-1.7.3/priv/lib/trace_file_drv.so > >> >> /usr/lib64/erlang/lib/runtime_tools-1.7.3/priv/lib/trace_ip_drv.so > >> >> /usr/lib64/erlang/lib/megaco-3.9.1.1/priv/lib/megaco_flex_scanner_drv_mt.so > >> >> /usr/lib64/erlang/lib/megaco-3.9.1.1/priv/lib/megaco_flex_scanner_drv.so > >> >> /usr/lib64/erlang/lib/erl_interface-3.5.9/bin/erl_call > >> >> /usr/lib64/erlang/lib/ssl-3.10/priv/bin/ssl_esock > >> >> /usr/lib64/erlang/lib/asn1-1.6.2/priv/lib/asn1_erl_drv.so > >> >> /usr/lib64/erlang/lib/crypto-1.5.3/priv/lib/crypto_drv.so > >> >> /usr/lib64/erlang/lib/common_test-1.3.4/priv/lib/erl_rx_driver.so > >> >> /usr/lib64/erlang/erts-5.6.5/bin/child_setup > >> >> > >> >> Before digging into the Makefiles, I'd like to know if you already > >> >> have some ideas about the root cause of this issue. > >> >> > >> > > >> > This bug is still present in R13A. > >> > > >> > ?* QA Notice: Files built without respecting LDFLAGS have been detected > >> > ?* ?Please include the following list of files in your report: > >> > ?* /usr/lib64/erlang/lib/runtime_tools-1.8/priv/lib/trace_file_drv.so > >> > ?* /usr/lib64/erlang/lib/runtime_tools-1.8/priv/lib/trace_ip_drv.so > >> > ?* /usr/lib64/erlang/lib/erl_interface-3.6/bin/erl_call > >> > ?* /usr/lib64/erlang/lib/crypto-1.6/priv/lib/crypto_drv.so > >> > ?* /usr/lib64/erlang/lib/megaco-3.10.0.1/priv/lib/megaco_flex_scanner_drv_mt.so > >> > ?* /usr/lib64/erlang/lib/megaco-3.10.0.1/priv/lib/megaco_flex_scanner_drv.so > >> > ?* /usr/lib64/erlang/lib/ssl-3.10.1/priv/bin/ssl_esock > >> > ?* /usr/lib64/erlang/lib/asn1-1.6.8/priv/lib/asn1_erl_drv.so > >> > ?* /usr/lib64/erlang/erts-5.7/bin/child_setup > >> > > >> > Best regards, > >> > Davide > >> > > >> > >> The attached patch fixes the problem for me: LDFLAGS are now respected. > >> > >> Regards, > >> Davide > > > > The patch looks great! It is unfortunately a few days late to make > > it into R13B. Now the source tree is labeled, and cut in stone. > > We have applied it, and it will be in the first patch release. > > > > We will also release it as a source code patch immediately > > after the R13B release. > > > > More patches like that! (and earlier)-: > > > > > > -- > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > > As far as I can see the patch has not been applied, or at least it's > not present in R13B01. Has it been lost? Yes. It has been lost. Sorry about that, and sorry about the delayed answer. This took some digging to find out there was no trace of the patch, not even in the wrong places. To be continued... > > Regards, > Davide > > ________________________________________________________________ > erlang-patches mailing list. See http://www.erlang.org/faq.html > erlang-patches (at) erlang.org -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From nick@REDACTED Sat Sep 5 19:55:57 2009 From: nick@REDACTED (Niclas Eklund) Date: Sat, 5 Sep 2009 19:55:57 +0200 (CEST) Subject: [erlang-bugs] Erlang R13B01 ssh and crypto module patch of aes128-cbc support on ssh In-Reply-To: <20090813100926.GA12085@k2r.org> References: <20090813100926.GA12085@k2r.org> Message-ID: Hello! The crypto stuff will make into R13B02 and hopefullly also the SSH fixes as well. /Niclas @ Erlang/OTP On Thu, 13 Aug 2009, Kenji Rikitake wrote: > The following patch includes a feature enhancement of Erlang R13B01 ssh > and crypto modules to support aes128-cbc mode on SSH. > > BUG FOUND: ssh_transport:unpack/3 causes crypto:aes_cbc_ivec/1 to crash, > by passing a null binary (<<>>), which causes erlang:split_binary/2 to > crash by badarg. > > By tracing the exchange between a FreeBSD OpenSSH implementation, I > found a case where the internal variable SshLength in > ssh_transport:unpack/3 goes to zero, which leads to passing a null > binary as an argument to ssh_transport:decrypt_blocks/3 and to > aes_cbc_ivec/1. So I added a case statement to avoid calling the > decrypt_blocks/3 when SshLength = 0. > > Patches follow. > > Kenji Rikitake > > --- lib/ssh/src/ssh_transport.erl.FCS 2009-06-05 21:55:34.000000000 +0900 > +++ lib/ssh/src/ssh_transport.erl 2009-08-13 17:42:28.000000000 +0900 > @@ -228,8 +228,10 @@ > cookie = Random, > kex_algorithms = ["diffie-hellman-group1-sha1"], > server_host_key_algorithms = ["ssh-rsa", "ssh-dss"], > - encryption_algorithms_client_to_server = ["3des-cbc"], > - encryption_algorithms_server_to_client = ["3des-cbc"], > + %% encryption_algorithms_client_to_server = ["3des-cbc"], > + %% encryption_algorithms_server_to_client = ["3des-cbc"], > + encryption_algorithms_client_to_server = ["aes128-cbc","3des-cbc"], > + encryption_algorithms_server_to_client = ["aes128-cbc","3des-cbc"], > mac_algorithms_client_to_server = ["hmac-sha1"], > mac_algorithms_server_to_client = ["hmac-sha1"], > compression_algorithms_client_to_server = Compression, > @@ -243,8 +245,10 @@ > cookie = Random, > kex_algorithms = ["diffie-hellman-group1-sha1"], > server_host_key_algorithms = ["ssh-dss"], > - encryption_algorithms_client_to_server = ["3des-cbc"], > - encryption_algorithms_server_to_client = ["3des-cbc"], > + %% encryption_algorithms_client_to_server = ["3des-cbc"], > + %% encryption_algorithms_server_to_client = ["3des-cbc"], > + encryption_algorithms_client_to_server = ["aes128-cbc","3des-cbc"], > + encryption_algorithms_server_to_client = ["aes128-cbc","3des-cbc"], > mac_algorithms_client_to_server = ["hmac-sha1"], > mac_algorithms_server_to_client = ["hmac-sha1"], > compression_algorithms_client_to_server = Compression, > @@ -703,6 +707,9 @@ > > unpack(EncodedSoFar, ReminingLenght, #ssh{recv_mac_size = MacSize} = Ssh0) -> > SshLength = ReminingLenght - MacSize, > + %%?dbg(?DBG_CRYPTO, > + %% "unpack: EncodedsoFar=~p SshLength=~p ReminingLenght=~p MacSize=~p ~n", > + %% [EncodedSoFar, SshLength, ReminingLenght, MacSize]), > {NoMac, Mac, Rest} = case MacSize of > 0 -> > < @@ -714,8 +721,16 @@ > Rest0/binary>> = EncodedSoFar, > {NoMac0, Mac0, Rest0} > end, > - {Ssh1, DecData, <<>>} = > - ssh_transport:decrypt_blocks(NoMac, SshLength, Ssh0), > + %%?dbg(?DBG_CRYPTO, "unpack: NoMac=~p Mac=~p Rest=~p ~n", > + %% [NoMac, Mac, Rest]), > + {Ssh1, DecData, <<>>} = case SshLength of > + 0 -> > + {Ssh0, <<>>, <<>>}; > + _ -> > + ssh_transport:decrypt_blocks(NoMac, SshLength, Ssh0) > + end, > + %%?dbg(?DBG_CRYPTO, "unpack: Ssh1=~p DecData=~p Rest=~p Mac=~p ~n", > + %% [Ssh1, DecData, Rest, Mac]), > {Ssh1, DecData, Rest, Mac}. > > msg_data(PacketData) -> > @@ -800,6 +815,18 @@ > <> = hash(Ssh, "D", 192), > {ok, Ssh#ssh{encrypt_keys = {K1,K2,K3}, > encrypt_block_size = 8, > + encrypt_ctx = IV}}; > +encrypt_init(#ssh{encrypt = 'aes128-cbc', role = client} = Ssh) -> > + IV = hash(Ssh, "A", 128), > + <> = hash(Ssh, "C", 128), > + {ok, Ssh#ssh{encrypt_keys = K, > + encrypt_block_size = 16, > + encrypt_ctx = IV}}; > +encrypt_init(#ssh{encrypt = 'aes128-cbc', role = server} = Ssh) -> > + IV = hash(Ssh, "B", 128), > + <> = hash(Ssh, "D", 128), > + {ok, Ssh#ssh{encrypt_keys = K, > + encrypt_block_size = 16, > encrypt_ctx = IV}}. > > encrypt_final(Ssh) -> > @@ -815,10 +842,19 @@ > encrypt_keys = {K1,K2,K3}, > encrypt_ctx = IV0} = Ssh, Data) -> > %%?dbg(?DBG_CRYPTO, "encrypt: IV=~p K1=~p, K2=~p, K3=~p ~n", > - %% [IV0,K1,K2,K3]), > + %% [IV0,K1,K2,K3]), > Enc = crypto:des3_cbc_encrypt(K1,K2,K3,IV0,Data), > %%?dbg(?DBG_CRYPTO, "encrypt: ~p -> ~p ~n", [Data, Enc]), > IV = crypto:des_cbc_ivec(Enc), > + {Ssh#ssh{encrypt_ctx = IV}, Enc}; > +encrypt(#ssh{encrypt = 'aes128-cbc', > + encrypt_keys = K, > + encrypt_ctx = IV0} = Ssh, Data) -> > + %%?dbg(?DBG_CRYPTO, "encrypt: IV=~p K=~p ~n", > + %% [IV0,K]), > + Enc = crypto:aes_cbc_128_encrypt(K,IV0,Data), > + %%?dbg(?DBG_CRYPTO, "encrypt: ~p -> ~p ~n", [Data, Enc]), > + IV = crypto:aes_cbc_ivec(Enc), > {Ssh#ssh{encrypt_ctx = IV}, Enc}. > > > @@ -840,7 +876,21 @@ > hash(Ssh, "C", 192)}, > <> = KD, > {ok, Ssh#ssh{decrypt_keys = {K1, K2, K3}, decrypt_ctx = IV, > - decrypt_block_size = 8}}. > + decrypt_block_size = 8}}; > + > +decrypt_init(#ssh{decrypt = 'aes128-cbc', role = client} = Ssh) -> > + {IV, KD} = {hash(Ssh, "B", 128), > + hash(Ssh, "D", 128)}, > + <> = KD, > + {ok, Ssh#ssh{decrypt_keys = K, decrypt_ctx = IV, > + decrypt_block_size = 16}}; > + > +decrypt_init(#ssh{decrypt = 'aes128-cbc', role = server} = Ssh) -> > + {IV, KD} = {hash(Ssh, "A", 128), > + hash(Ssh, "C", 128)}, > + <> = KD, > + {ok, Ssh#ssh{decrypt_keys = K, decrypt_ctx = IV, > + decrypt_block_size = 16}}. > > decrypt_final(Ssh) -> > {ok, Ssh#ssh {decrypt = none, > @@ -858,6 +908,14 @@ > Dec = crypto:des3_cbc_decrypt(K1,K2,K3,IV0,Data), > %%?dbg(?DBG_CRYPTO, "decrypt: ~p -> ~p ~n", [Data, Dec]), > IV = crypto:des_cbc_ivec(Data), > + {Ssh#ssh{decrypt_ctx = IV}, Dec}; > +decrypt(#ssh{decrypt = 'aes128-cbc', decrypt_keys = Key, > + decrypt_ctx = IV0} = Ssh, Data) -> > + %%?dbg(?DBG_CRYPTO, "decrypt: IV=~p Key=~p ~n", > + %% [IV0,Key]), > + Dec = crypto:aes_cbc_128_decrypt(Key,IV0,Data), > + %%?dbg(?DBG_CRYPTO, "decrypt: ~p -> ~p ~n", [Data, Dec]), > + IV = crypto:aes_cbc_ivec(Data), > {Ssh#ssh{decrypt_ctx = IV}, Dec}. > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > --- lib/crypto/src/crypto.erl.FCS 2009-03-12 21:28:35.000000000 +0900 > +++ lib/crypto/src/crypto.erl 2009-08-13 13:27:09.000000000 +0900 > @@ -45,6 +45,7 @@ > %% -export([idea_cbc_encrypt/3, idea_cbc_decrypt/3]). > -export([aes_cbc_128_encrypt/3, aes_cbc_128_decrypt/3]). > -export([aes_cbc_256_encrypt/3, aes_cbc_256_decrypt/3]). > +-export([aes_cbc_ivec/1]). > > -export([dh_generate_parameters/2, dh_check/1]). %% Testing see below > > @@ -469,6 +470,19 @@ > control(?AES_CBC_256_DECRYPT, [Key, IVec, Data]). > > %% > +%% aes_cbc_ivec(Data) -> binary() > +%% > +%% Returns the IVec to be used in the next iteration of > +%% aes_cbc_*_[encrypt|decrypt]. > +%% IVec size: 16 bytes > +%% > +aes_cbc_ivec(Data) when is_binary(Data) -> > + {_, IVec} = split_binary(Data, size(Data) - 16), > + IVec; > +aes_cbc_ivec(Data) when is_list(Data) -> > + aes_cbc_ivec(list_to_binary(Data)). > + > +%% > %% XOR - xor to iolists and return a binary > %% NB doesn't check that they are the same size, just concatenates > %% them and sends them to the driver > From vinoski@REDACTED Wed Sep 16 16:52:33 2009 From: vinoski@REDACTED (Steve Vinoski) Date: Wed, 16 Sep 2009 10:52:33 -0400 Subject: patch for sys:get_status to call format_status/2 In-Reply-To: <65b2728e0908260612yfd6c1c9ke8f6f3d9a5b652f8@mail.gmail.com> References: <65b2728e0908260612yfd6c1c9ke8f6f3d9a5b652f8@mail.gmail.com> Message-ID: <65b2728e0909160752n5759306fy76f7f195bf07ad@mail.gmail.com> I've never gotten any replies offering an opinion on whether or not the patch below is acceptable. Has anyone had a chance to evaluate it yet? Just curious. thanks, --steve On Wed, Aug 26, 2009 at 9:12 AM, Steve Vinoski wrote: > [I've been trying to send this patch to erlang-bugs and erlang-questions > for the past few days, but it hasn't shown up. Trying erlang-patches this > time.] > Back in March of this year the following thread appeared in > erlang-questions regarding the undocumented format_status/2 function that > apparently used to be called by sys:get_status if provided by a behavior > module: > > > > I searched back all the way to version R6B but found no code that made > that call except within SASL's si_sasl_supp module, yet I see that > various modules such as gen_server, gen_event, gen_fsm, and os_mon's disksup > and memsup each provide a format_status/2 function, plus the generic > behaviors also check to see if modules implementing them also provide > a format_status/2 function, calling it if they do and thus allowing you > to format how sys:get_status prints out your gen_server, gen_fsm, etc. > state. Seems like a shame to let that code go to waste! :-) I agree with > the originator of that thread that being allowed to provide a > special format_status/2 when implementing a behavior can be very handy, so > below find a simple patch for R13B01 that implements it. > > --steve > > --- lib/stdlib/src/sys.erl~ 2009-03-12 08:18:15.000000000 -0400 > +++ lib/stdlib/src/sys.erl 2009-08-26 01:25:13.000000000 -0400 > @@ -245,8 +245,17 @@ > {SysState, {error, {unknown_system_msg, Other}}, Debug, Misc}. > > get_status(SysState, Parent, Mod, Debug, Misc) -> > + PDict = get(), > + FmtMisc = > + case erlang:function_exported(Mod, format_status, 2) of > + true -> > + FmtArgs = [PDict, SysState, Parent, Debug, Misc], > + Mod:format_status(normal, FmtArgs); > + _ -> > + Misc > + end, > {status, self(), {module, Mod}, > - [get(), SysState, Parent, Debug, Misc]}. > + [PDict, SysState, Parent, Debug, FmtMisc]}. > > %%----------------------------------------------------------------- > %% These are the system debug commands. > > From vances@REDACTED Wed Sep 16 18:33:23 2009 From: vances@REDACTED (Vance Shipley) Date: Wed, 16 Sep 2009 12:33:23 -0400 Subject: [erlang-patches] Re: patch for sys:get_status to call format_status/2 In-Reply-To: <65b2728e0909160752n5759306fy76f7f195bf07ad@mail.gmail.com> References: <65b2728e0908260612yfd6c1c9ke8f6f3d9a5b652f8@mail.gmail.com> <65b2728e0909160752n5759306fy76f7f195bf07ad@mail.gmail.com> Message-ID: <20090916163323.GB6186@h216-235-12-172.host.egate.net> Steve, As the original one to mourn the passing of this feature, which I used all the time, I fully support you. I hope your patch will be accepted. -Vance On Wed, Sep 16, 2009 at 10:52:33AM -0400, Steve Vinoski wrote: } I've never gotten any replies offering an opinion on whether or not the } patch below is acceptable. Has anyone had a chance to evaluate it yet? Just } curious. } thanks, From badlop@REDACTED Wed Sep 23 14:41:05 2009 From: badlop@REDACTED (Badlop) Date: Wed, 23 Sep 2009 14:41:05 +0200 Subject: Patch to fix 630 English typos in documentation Message-ID: <732f49190909230541r7629c210u6077712c4e971d1@mail.gmail.com> Hello, The attached patch fixes 630 English spelling typos in 198 documentation files. It is not comprehensive. For instance, the automated spell checking was limited to verify only lowercase words. During my manual verification I also discarded some changes. The typos were originally extracted from R13B01 documentation, but I've updated the patch to apply to R13B02, and manually verified it again. --- Badlop ProcessOne -------------- next part -------------- A non-text attachment was scrubbed... Name: spell-fixes-r13b02.diff.bz2 Type: application/x-bzip2 Size: 73664 bytes Desc: not available URL: From akitada@REDACTED Thu Sep 24 10:39:50 2009 From: akitada@REDACTED (Akira Kitada) Date: Thu, 24 Sep 2009 17:39:50 +0900 Subject: Missing patch in R13B02-1 for fixing build time segmentation fault Message-ID: <90bb445a0909240139g2cfbef3cnff47b571315330f@mail.gmail.com> Hi, I'm resubmitting Michael Turner's patch which seemingly missed in R13B02(-1) release. The original report is below. I confirmed this patch fixes the build issue in R13B02-1. Please consider including this in the next release. Thanks, Akira ---------- Forwarded message ---------- From: Michael Turner Date: Wed, Jul 29, 2009 at 5:34 PM Subject: [erlang-bugs] R12B01 erl_misc_utils.c stack-trashing bug, + a patch To: erlang-bugs@REDACTED Was trying to build on a i386_unknown_freebsd4.10, with a gcc about 10 years old. ?The build died in /lib/parsetools/src. ?gdb revealed revealed a trashed stack. The source of the problem became clear after narrowing it down to a function in erl_misc_utils.c. ?There are assignments to mib[0] and mib[1], with mib declared size zero. (Yes. ?sizeof (mib) == 0. ?The first time I've ever seen that. ?And the last, I hope.) Dimension of 2 for mib[] seemed appropriate in context. ?The build continued after that fix. ========== --- otp_src_R13B01/erts/lib_src/common/erl_misc_utils.c.~1~ ? ? Wed Jul 29 00:53:30 2009 +++ otp_src_R13B01/erts/lib_src/common/erl_misc_utils.c Tue Jul 28 22:17:45 2009 @@ -172,7 +172,7 @@ erts_cpu_info_update(erts_cpu_info_t *cp ?#elif defined(HAVE_SYS_SYSCTL_H) && defined(CTL_HW) && (defined(HW_NCPU) \ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| defined(HW_AVAILCPU)) ? ? { - ? ? ? int mib[0]; + ? ? ? int mib[2]; ? ? ? ?size_t len; #ifdef HW_NCPU ________________________________________________________________ erlang-bugs mailing list. See http://www.erlang.org/faq.html erlang-bugs (at) erlang.org From rickard.s.green@REDACTED Thu Sep 24 16:14:09 2009 From: rickard.s.green@REDACTED (Rickard Green) Date: Thu, 24 Sep 2009 16:14:09 +0200 Subject: Missing patch in R13B02-1 for fixing build time segmentation fault In-Reply-To: <90bb445a0909240139g2cfbef3cnff47b571315330f@mail.gmail.com> References: <90bb445a0909240139g2cfbef3cnff47b571315330f@mail.gmail.com> Message-ID: <4ABB7EB1.9090602@ericsson.com> Hmm, I was sure that I had included this patch in an earlier release, but obviously I had not. Sorry. I will be included in R13B03. Regards, Rickard -- Rickard Green, Erlang/OTP, Ericsson AB. Akira Kitada wrote: > Hi, > > I'm resubmitting Michael Turner's patch which seemingly missed in > R13B02(-1) release. > The original report is below. > I confirmed this patch fixes the build issue in R13B02-1. > > Please consider including this in the next release. > > Thanks, > Akira > > ---------- Forwarded message ---------- > From: Michael Turner > Date: Wed, Jul 29, 2009 at 5:34 PM > Subject: [erlang-bugs] R12B01 erl_misc_utils.c stack-trashing bug, + a patch > To: erlang-bugs@REDACTED > > > > Was trying to build on a i386_unknown_freebsd4.10, with a gcc about 10 > years old. The build died in /lib/parsetools/src. gdb revealed > revealed a trashed stack. > > The source of the problem became clear after narrowing it down to a > function in erl_misc_utils.c. There are assignments to mib[0] and > mib[1], with mib declared size zero. (Yes. sizeof (mib) =0. The > first time I've ever seen that. And the last, I hope.) > > Dimension of 2 for mib[] seemed appropriate in context. The build > continued after that fix. > > ======= > --- otp_src_R13B01/erts/lib_src/common/erl_misc_utils.c.~1~ Wed Jul 29 > 00:53:30 2009 > +++ otp_src_R13B01/erts/lib_src/common/erl_misc_utils.c Tue Jul 28 > 22:17:45 2009 > @@ -172,7 +172,7 @@ erts_cpu_info_update(erts_cpu_info_t *cp > #elif defined(HAVE_SYS_SYSCTL_H) && defined(CTL_HW) && (defined(HW_NCPU) > \ > || defined(HW_AVAILCPU)) > { > - int mib[0]; > + int mib[2]; > size_t len; > > #ifdef HW_NCPU > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > From hakan@REDACTED Thu Sep 24 16:36:59 2009 From: hakan@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Thu, 24 Sep 2009 16:36:59 +0200 Subject: [erlang-patches] Re: Missing patch in R13B02-1 for fixing build time segmentation fault In-Reply-To: <4ABB7EB1.9090602@ericsson.com> References: <90bb445a0909240139g2cfbef3cnff47b571315330f@mail.gmail.com> <4ABB7EB1.9090602@ericsson.com> Message-ID: <922d05850909240736o60f4e74fna752a3ed6c7a6a7d@mail.gmail.com> On Thu, Sep 24, 2009 at 4:14 PM, Rickard Green wrote: > I will be included in R13B03. I suspect that you do not fit into the next release. But you can always try by including an experimental version of yourself without beard. ;-) /H?kan From dangud@REDACTED Thu Sep 24 19:16:50 2009 From: dangud@REDACTED (Dan Gudmundsson) Date: Thu, 24 Sep 2009 19:16:50 +0200 Subject: [erlang-patches] Missing patch in R13B02-1 for fixing build time segmentation fault In-Reply-To: <922d05850909240736o60f4e74fna752a3ed6c7a6a7d@mail.gmail.com> References: <90bb445a0909240139g2cfbef3cnff47b571315330f@mail.gmail.com> <4ABB7EB1.9090602@ericsson.com> <922d05850909240736o60f4e74fna752a3ed6c7a6a7d@mail.gmail.com> Message-ID: <93df43b60909241016r32ee7fle9bf8eb0b1ecf508@mail.gmail.com> Rickard might have forgotten a t in a word but you forgot a meta-t between Olddir Newdir. I dont know what is worse :-) 2009/9/24, H?kan Mattsson : > On Thu, Sep 24, 2009 at 4:14 PM, Rickard Green > wrote: >> I will be included in R13B03. > > I suspect that you do not fit into the next release. But you can always > try by including an experimental version of yourself without beard. ;-) > > /H?kan > > ________________________________________________________________ > erlang-patches mailing list. See http://www.erlang.org/faq.html > erlang-patches (at) erlang.org > > From nesrait@REDACTED Fri Sep 25 14:55:31 2009 From: nesrait@REDACTED (=?ISO-8859-1?Q?Davide_Marqu=EAs?=) Date: Fri, 25 Sep 2009 13:55:31 +0100 Subject: Fixes for building erlang under windows Message-ID: <523869a70909250555h13b355bdn14eadadccb7afb51@mail.gmail.com> Hi all, Here are some fixes I picked up along the way while building erlang on a fresh install of Windows. Fix for cygwin environments that might have non-default cygdrive prefixes: > $ERL_TOP/erts/configure.in: > 3242: > open_ssl_default_dir=`cygpath "c:\OpenSSL"` > for dir in $extra_dir $open_ssl_default_dir \ > 3493: > kerberos_default_dir=`cygpath "c:\kerberos"` > SSL_KRB5_INCLUDE= > if test "x$ssl_krb5_enabled" = "xyes" ; then > AC_MSG_CHECKING(for krb5.h in standard locations) > for dir in $extra_dir $SSL_ROOT/include $SSL_ROOT/include/openssl \ > $SSL_ROOT/include/kerberos $kerberos_default_dir/include \ > > > $ERL_TOP/erts/configure: > 21867: > open_ssl_default_dir=`cygpath "c:\OpenSSL"` > for dir in $extra_dir $open_ssl_default_dir \ > 22235: > kerberos_default_dir=`cygpath "c:\kerberos"` > SSL_KRB5_INCLUDE= > if test "x$ssl_krb5_enabled" = "xyes" ; then > echo "$as_me:$LINENO: checking for krb5.h in standard > locations" >&5 > echo $ECHO_N "checking for krb5.h in standard locations... $ECHO_C" >&6 > for dir in $extra_dir $SSL_ROOT/include $SSL_ROOT/include/openssl \ > $SSL_ROOT/include/kerberos $kerberos_default_dir/include \ > Needed changes for OpenSSL installations in non-default paths: > Using the "--with-ssl" option in configure (EVEN IF OpenSSL is installed > in a default location) will set the SSL_LIBDIR variable to an incorrect > value > and crypto and ssh compilation will fail. > > - If OpenSSL is found in the default location: > $ ./otp_build configure > ... > $ grep "SSL_LIBDIR =" lib/crypto/c_src/win32/Makefile > SSL_LIBDIR = /c/OpenSSL/lib > > - Otherwise if we provide the path to OpenSSL: > $ ./otp_build configure --with-ssl="/c/OpenSSL" > ... > $ grep "SSL_LIBDIR =" lib/crypto/c_src/win32/Makefile > SSL_LIBDIR = /c/OpenSSL/lib/VC > > $ERL_TOP/erts/configure:22139 > $ERL_TOP/erts/configure.in:3418 > if test "x$MIXED_CYGWIN" = "xyes" -a -d "$with_ssl/lib/VC"; then > SSL_LIBDIR="$with_ssl/lib/VC" > should include the additional tests: > if test "x$MIXED_CYGWIN" = "xyes" ; then > if test -f "$dir/lib/VC/ssleay32.lib" -o \ > -f "$dir/lib/VC/openssl.lib"; then > SSL_LIBDIR="$dir/lib/VC" > elif test -f "$dir/lib/ssleay32.lib" -o \ > -f "$dir/lib/openssl.lib"; then > SSL_LIBDIR="$dir/lib" > else > is_real_ssl=no > fi > that are done when looking open OpenSSL in the default paths > ($ERL_TOP/erts/configure.in:21867 and $ERL_TOP/erts/configure:3242). > Others... > $ERL_TOP/erts/etc/win32/cygwin_tools/vc/mc.sh: > 70: > if [ "X$MC_SH_DEBUG_LOG" != "X" ]; then > echo mc.sh "$SAVE" >>$MC_SH_DEBUG_LOG > echo $MCC $CMD >>$MC_SH_DEBUG_LOG > fi > > Comparing line 33 of $ERL_TOP/erts/etc/win32/cygwin_tools/vc/mc.sh: > if [ -n "`$p/mc.exe -? 2>&1 >/dev/null | grep -i \"message compiler\"`" ]; then > MCC=$p/mc.exe > fi > with line 33 of $ERL_TOP/erts/etc/win32/cygwin_tools/vc/rc.sh: > if [ -n "`$p/rc.exe -? 2>&1 | grep -i "resource compiler"`" ]; then > RCC=$p/rc.exe > fi > It seems the second one needs some escaping: \"resource compiler\". > That's it for now. I'm rewriting a step-by-step tutorialon how to build erlang under windows using Visual C++ Express 2008 which I'll share when complete (wxWidgets and gs are still giving me an hard time). Cheers, :Davide From puzza007@REDACTED Mon Sep 28 00:35:33 2009 From: puzza007@REDACTED (Paul Oliver) Date: Sun, 27 Sep 2009 23:35:33 +0100 Subject: [erlang-questions] blowfish ECB implementation in erlang? In-Reply-To: References: <38ff4e6b0909231233i4435a436v170a8b1953b22c4e@mail.gmail.com> Message-ID: On Fri, Sep 25, 2009 at 1:19 PM, Paul Oliver wrote: > On Wed, Sep 23, 2009 at 8:33 PM, Larry Ogrodnek wrote: > >> Hi, I'm wondering if anyone has put together an implementation of blowfish >> ECB? >> >> thanks. >> > > Hi Larry, > > Check the following page for the patch that added cfb64. > > > http://www.nabble.com/Patch-to-add-Blowfish-cfb64-to-crypto-app-td24232164.html > > You should almost be able to copy this verbatim to add ecb. > > Cheers, > Paul. > Hi Larry, The attached patch should do ECB for you. It works for me on the test data I obtained from http://www.schneier.com/code/vectors.txt. puzza@REDACTED:~/Downloads/otp_src_R13B02-1$ /tmp/bin/erl Erlang R13B02 (erts-5.7.3) [source] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false] Eshell V5.7.3 (abort with ^G) 1> %% FEDCBA9876543210 == Key = <<254,220,186,152,118,84,50,16>> 1> %% 0123456789ABCDEF == Clear = <<1,35,69,103,137,171,205,239>> 1> %% 0ACEAB0FC6A0A28D == Enc = <<10,206,171,15,198,160,162,141>> 1> 1> crypto:start(). ok 2> Key = <<254,220,186,152,118,84,50,16>>. <<254,220,186,152,118,84,50,16>> 3> Clear = <<1,35,69,103,137,171,205,239>>. <<1,35,69,103,137,171,205,239>> 4> Enc = <<10,206,171,15,198,160,162,141>>. <<10,206,171,15,198,160,162,141>> 5> Enc == crypto:blowfish_ecb_encrypt(Key, Clear). true 6> Clear == crypto:blowfish_ecb_decrypt(Key, Enc). true 7> I'm off on holiday tomorrow so if it doesn't work as it should I'll take another look in a couple of weeks. ;} If it works OK please reply and perhaps it can be picked up in a future OTP release. Cheers, Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Blowfish-ECB.patch Type: application/octet-stream Size: 4318 bytes Desc: not available URL: From nesrait@REDACTED Mon Sep 28 02:31:16 2009 From: nesrait@REDACTED (=?ISO-8859-1?Q?Davide_Marqu=EAs?=) Date: Mon, 28 Sep 2009 01:31:16 +0100 Subject: Fixes for building erlang under windows In-Reply-To: <523869a70909250555h13b355bdn14eadadccb7afb51@mail.gmail.com> References: <523869a70909250555h13b355bdn14eadadccb7afb51@mail.gmail.com> Message-ID: <523869a70909271731v6f1b3492y2246c8ae69a94088@mail.gmail.com> Hi again! The gs application build fails under windows due to a missing binaries/win32.tar.gz. The configure step does check to see whether the file exists but the Makefile ignores that test result and overrides/corrects the TCL_TAR value even if the file is missing. The fix: $ERL_TOP/lib/gs/tcl/Makefile.in:36 Replace: ifeq ($(TARGET),win32) TCL_TAR = binaries/win32.tar.gz else TCL_TAR = @TCL_TAR@ endif by: TCL_TAR = @TCL_TAR@ ifneq ($(TCL_TAR),) ifeq ($(TARGET),win32) TCL_TAR = binaries/win32.tar.gz endif endif One down, one (wxWidgets) to go. Cheers, :Davide From jmuellerleile@REDACTED Mon Sep 28 02:53:35 2009 From: jmuellerleile@REDACTED (John Muellerleile) Date: Sun, 27 Sep 2009 20:53:35 -0400 Subject: Bug+patch: jinterface, OtpInputStream.java: com.ericsson.otp.erlang.OtpErlangDecodeException: Decompression gave n bytes, not ... Message-ID: Hi, R13B01 on Mac OS X, JDK 1.6.0_07, using jinterface to send messages from erlang to a java node; depending on message size I would encounter: ---- com.ericsson.otp.erlang.OtpErlangDecodeException: Decompression gave 806 bytes, not 1023 at com.ericsson.otp.erlang.OtpInputStream.read_compressed(OtpInputStream.java:1121) at com.ericsson.otp.erlang.OtpInputStream.read_any(OtpInputStream.java:1195) at com.ericsson.otp.erlang.OtpErlangObject.decode(OtpErlangObject.java:70) [....] ---- After a bit of poking around, the following change to OtpInputStream.java seems to fix it: Change OtpInputStream.java, line 1114,1115 from: final java.util.zip.InflaterInputStream is = new java.util.zip.InflaterInputStream(this); to: final java.util.zip.InflaterInputStream is = new java.util.zip.InflaterInputStream(this, new java.util.zip.Inflater(), size); 'size' being the important part; the default InflaterInputStream buffer size is 512 bytes (InflaterInputStream.java, line ~98); seems when the inflater buffer has filled it returns what has been decompressed so far. To test, in OtpInputStream.java place a check for "is.available()" after if(dsize != size): if the value returned is 1 there is data remaining to be read. Supplying the size established by read4BE() to InflaterInputStream eliminates this behavior. John From mazen.harake@REDACTED Mon Sep 28 08:09:29 2009 From: mazen.harake@REDACTED (Mazen Harake) Date: Mon, 28 Sep 2009 08:09:29 +0200 Subject: [erlang-patches] Re: Fixes for building erlang under windows In-Reply-To: <523869a70909271731v6f1b3492y2246c8ae69a94088@mail.gmail.com> References: <523869a70909250555h13b355bdn14eadadccb7afb51@mail.gmail.com> <523869a70909271731v6f1b3492y2246c8ae69a94088@mail.gmail.com> Message-ID: <4AC05319.9070103@erlang-consulting.com> What's wrong with wxWidgets? /Mazen Davide Marqu?s wrote: > Hi again! > > The gs application build fails under windows due to a missing > binaries/win32.tar.gz. > The configure step does check to see whether the file exists but the > Makefile ignores > that test result and overrides/corrects the TCL_TAR value even if the file > is missing. > > The fix: > $ERL_TOP/lib/gs/tcl/Makefile.in:36 > > Replace: > ifeq ($(TARGET),win32) > TCL_TAR = binaries/win32.tar.gz > else > TCL_TAR = @TCL_TAR@ > endif > > by: > TCL_TAR = @TCL_TAR@ > ifneq ($(TCL_TAR),) > ifeq ($(TARGET),win32) > TCL_TAR = binaries/win32.tar.gz > endif > endif > > One down, one (wxWidgets) to go. > > Cheers, > :Davide > > From nesrait@REDACTED Mon Sep 28 12:06:57 2009 From: nesrait@REDACTED (=?ISO-8859-1?Q?Davide_Marqu=EAs?=) Date: Mon, 28 Sep 2009 11:06:57 +0100 Subject: [erlang-patches] Re: Fixes for building erlang under windows In-Reply-To: <4AC05319.9070103@erlang-consulting.com> References: <523869a70909250555h13b355bdn14eadadccb7afb51@mail.gmail.com> <523869a70909271731v6f1b3492y2246c8ae69a94088@mail.gmail.com> <4AC05319.9070103@erlang-consulting.com> Message-ID: <523869a70909280306y571f147wd4f2569fb8fcacb9@mail.gmail.com> Hi Mazen, Simply going through the steps in README.win32 doesn't seem to be enough for configure to pick up the wxWidgets installation/libraries. These were the steps I took: - run the wxWidgets-2.8.10 installer; - edit /include/wx/msw/setup.h and enable: - wxUSE_GLCANVAS - wxUSE_POSTSCRIPT - wxUSE_GRAPHICS_CONTEXT - open /build/msw/wx.dsw (letting VC convert the projects) - build the "Unicode Release" and "Unicode Debug" configurations - open /contrib/build/stc/stc.dsw (letting VC convert the projects) - build the "Unicode Release" and "Unicode Debug" configurations After which the C:\Program Files\wxWidgets-2.8.10\lib\vc_lib folder contais 195MB of .lib goodness (wxbase28d.lib, wxbase28u.lib, wxbase28d_net.lib, wxbase28u_net.lib, ...). This is the relevant part of the configure output: > checking for debug build of WxWidgets... checking for wx-config... no checking for standard build of WxWidgets... checking for wx-config... > (cached) no configure: WARNING: wxWidgets must be installed on your system. > Please check that wx-config is in path, the directory where wxWidgets libraries are installed (returned by 'wx-config --libs' or 'wx-config --static --libs' command) is in LD_LIBRARY_PATH or equivalent variable and wxWidgets version is 2.8.0 or above. checking GL/gl.h usability... no checking GL/gl.h presence... yes configure: WARNING: GL/gl.h: present but cannot be compiled configure: WARNING: GL/gl.h: check for missing prerequisite headers? configure: WARNING: GL/gl.h: see the Autoconf documentation configure: WARNING: GL/gl.h: section "Present But Cannot Be Compiled" configure: WARNING: GL/gl.h: proceeding with the preprocessor's result configure: WARNING: GL/gl.h: in the future, the compiler will take > precedence configure: WARNING: ## ------------------------------------------ ## configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ## configure: WARNING: ## ------------------------------------------ ## checking for GL/gl.h... yes checking OpenGL/gl.h usability... no checking OpenGL/gl.h presence... no checking for OpenGL/gl.h... no checking if wxwidgets have opengl support... no checking for GLintptr... no checking for GLintptrARB... no checking for GLchar... no checking for GLcharARB... no checking for GLhalfARB... no checking for GLint64EXT... no checking GLU Callbacks uses Tiger Style... no checking for wx/stc/stc.h... no configure: WARNING: Can not find wx/stc/stc.h checking if we can link wxwidgets programs... no configure: WARNING: Can not link wx program are all developer packages > installed? configure: creating i686-pc-cygwin/config.status config.status: creating config.mk config.status: creating c_src/Makefile The wx-config didn't exist at this point. As there was a wx-config.in file I ran configure to create it. But that didn't help much. Here are some of its outputs: VC2008: wxWidgets-2.8.10 $ ./wx-config --libs-L/c/Progra~1/wxWidgets-2.8.10/lib -lwx_msw_richtext-2.8 -lwx_msw_aui-2.8 -lwx_msw_xrc-2.8 -lwx_msw_qa-2.8 -lwx_msw_html-2.8 -lwx_msw_adv-2.8 -lwx_msw_core-2.8 -lwx_base_xml-2.8 -lwx_base_net-2.8 -lwx_base-2.8 VC2008: wxWidgets-2.8.10 $ ./wx-config --static --libs Warning: No config found to match: ./wx-config --static --libs in /c/Progra~1/wxWidgets-2.8.10/lib/wx/config If you require this configuration, please install the desired library build. If this is part of an automated configuration test and no other errors occur, you may safely ignore it. You may use wx-config --list to see all configs available in the default prefix. VC2008: wx $ wx-config --unicode --debug=yes Warning: No config found to match: /c/Progra~1/wxWidgets-2.8.10/wx-config --unicode --debug=yes in /c/Progra~1/wxWidgets-2.8.10/lib/wx/config If you require this configuration, please install the desired library build. If this is part of an automated configuration test and no other errors occur, you may safely ignore it. You may use wx-config --list to see all configs available in the default prefix. The configure fails after this last check: checking for debug build of WxWidgets... checking for wx-config... /c/Progra~1/wxWidgets-2.8.10/wx-config checking for wxWidgets version >= 2.8.0 (--unicode --debug=yes)... no checking for standard build of WxWidgets... checking for wx-config... (cached) / c/Progra~1/wxWidgets-2.8.10/wx-config checking for wxWidgets version >= 2.8.0 (--unicode --debug=no)... no configure: WARNING: wxWidgets must be installed on your system. Please check that wx-config is in path, the directory where wxWidgets libraries are installed (returned by 'wx-config --libs' or 'wx-config --static --libs' command) is in LD_LIBRARY_PATH or equivalent variable and wxWidgets version is 2.8.0 or above. I'm obviously clueless. Any tips? :) Cheers, :Davide From dgud@REDACTED Mon Sep 28 12:39:18 2009 From: dgud@REDACTED (Dan Gudmundsson) Date: Mon, 28 Sep 2009 12:39:18 +0200 Subject: [erlang-patches] Re: Fixes for building erlang under windows In-Reply-To: <523869a70909280306y571f147wd4f2569fb8fcacb9@mail.gmail.com> References: <523869a70909250555h13b355bdn14eadadccb7afb51@mail.gmail.com> <523869a70909271731v6f1b3492y2246c8ae69a94088@mail.gmail.com> <4AC05319.9070103@erlang-consulting.com> <523869a70909280306y571f147wd4f2569fb8fcacb9@mail.gmail.com> Message-ID: <4AC09256.5090802@erix.ericsson.se> From the README.win32 => Get and unpack wxWidgets-2.8.9 or higher to /opt/local/pgm inside cygwin ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The configure script only looks there on windows when building with VC++ We didn't try anything fancy for the windows build there are so few building from the source on that platform. /Dan Davide Marqu?s wrote: > Hi Mazen, > Simply going through the steps in README.win32 doesn't seem to be enough for > configure to pick up the wxWidgets installation/libraries. > > These were the steps I took: > - run the wxWidgets-2.8.10 installer; > - edit /include/wx/msw/setup.h and enable: > - wxUSE_GLCANVAS > - wxUSE_POSTSCRIPT > - wxUSE_GRAPHICS_CONTEXT > - open /build/msw/wx.dsw (letting VC convert the projects) > - build the "Unicode Release" and "Unicode Debug" configurations > - open /contrib/build/stc/stc.dsw (letting VC convert the > projects) > - build the "Unicode Release" and "Unicode Debug" configurations > After which the C:\Program Files\wxWidgets-2.8.10\lib\vc_lib folder contais > 195MB of .lib goodness (wxbase28d.lib, wxbase28u.lib, wxbase28d_net.lib, > wxbase28u_net.lib, ...). > > This is the relevant part of the configure output: > >> checking for debug build of WxWidgets... checking for wx-config... no > > checking for standard build of WxWidgets... checking for wx-config... >> (cached) no > > configure: WARNING: > > wxWidgets must be installed on your system. > > >> Please check that wx-config is in path, the directory > > where wxWidgets libraries are installed (returned by > > 'wx-config --libs' or 'wx-config --static --libs' command) > > is in LD_LIBRARY_PATH or equivalent variable and > > wxWidgets version is 2.8.0 or above. > > checking GL/gl.h usability... no > > checking GL/gl.h presence... yes > > configure: WARNING: GL/gl.h: present but cannot be compiled > > configure: WARNING: GL/gl.h: check for missing prerequisite headers? > > configure: WARNING: GL/gl.h: see the Autoconf documentation > > configure: WARNING: GL/gl.h: section "Present But Cannot Be Compiled" > > configure: WARNING: GL/gl.h: proceeding with the preprocessor's result > > configure: WARNING: GL/gl.h: in the future, the compiler will take >> precedence > > configure: WARNING: ## ------------------------------------------ ## > > configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ## > > configure: WARNING: ## ------------------------------------------ ## > > checking for GL/gl.h... yes > > checking OpenGL/gl.h usability... no > > checking OpenGL/gl.h presence... no > > checking for OpenGL/gl.h... no > > checking if wxwidgets have opengl support... no > > checking for GLintptr... no > > checking for GLintptrARB... no > > checking for GLchar... no > > checking for GLcharARB... no > > checking for GLhalfARB... no > > checking for GLint64EXT... no > > checking GLU Callbacks uses Tiger Style... no > > checking for wx/stc/stc.h... no > > configure: WARNING: Can not find wx/stc/stc.h > > checking if we can link wxwidgets programs... no > > configure: WARNING: Can not link wx program are all developer packages >> installed? > > configure: creating i686-pc-cygwin/config.status > > config.status: creating config.mk > > config.status: creating c_src/Makefile > > > The wx-config didn't exist at this point. As there was a wx-config.in file I > ran configure to create it. But that didn't help much. > > Here are some of its outputs: > > VC2008: wxWidgets-2.8.10 $ ./wx-config --libs-L/c/Progra~1/wxWidgets-2.8.10/lib > -lwx_msw_richtext-2.8 -lwx_msw_aui-2.8 -lwx_msw_xrc-2.8 -lwx_msw_qa-2.8 > -lwx_msw_html-2.8 -lwx_msw_adv-2.8 -lwx_msw_core-2.8 -lwx_base_xml-2.8 > -lwx_base_net-2.8 -lwx_base-2.8 > > VC2008: wxWidgets-2.8.10 $ ./wx-config --static --libs > > Warning: No config found to match: ./wx-config --static --libs > in /c/Progra~1/wxWidgets-2.8.10/lib/wx/config > If you require this configuration, please install the desired > library build. If this is part of an automated configuration > test and no other errors occur, you may safely ignore it. > You may use wx-config --list to see all configs available in > the default prefix. > > > VC2008: wx $ wx-config --unicode --debug=yes Warning: No config found to > match: /c/Progra~1/wxWidgets-2.8.10/wx-config --unicode --debug=yes > in /c/Progra~1/wxWidgets-2.8.10/lib/wx/config > If you require this configuration, please install the desired > library build. If this is part of an automated configuration > test and no other errors occur, you may safely ignore it. > You may use wx-config --list to see all configs available in > the default prefix. > > > The configure fails after this last check: > > checking for debug build of WxWidgets... checking for wx-config... > /c/Progra~1/wxWidgets-2.8.10/wx-config > checking for wxWidgets version >= 2.8.0 (--unicode --debug=yes)... no > checking for standard build of WxWidgets... checking for wx-config... > (cached) / > c/Progra~1/wxWidgets-2.8.10/wx-config > checking for wxWidgets version >= 2.8.0 (--unicode --debug=no)... no > configure: WARNING: > wxWidgets must be installed on your system. > > Please check that wx-config is in path, the directory > where wxWidgets libraries are installed (returned by > 'wx-config --libs' or 'wx-config --static --libs' command) > is in LD_LIBRARY_PATH or equivalent variable and > wxWidgets version is 2.8.0 or above. > > > I'm obviously clueless. Any tips? :) > > Cheers, > :Davide > From nesrait@REDACTED Mon Sep 28 13:15:04 2009 From: nesrait@REDACTED (=?ISO-8859-1?Q?Davide_Marqu=EAs?=) Date: Mon, 28 Sep 2009 12:15:04 +0100 Subject: [erlang-patches] Re: Fixes for building erlang under windows In-Reply-To: <4AC09256.5090802@erix.ericsson.se> References: <523869a70909250555h13b355bdn14eadadccb7afb51@mail.gmail.com> <523869a70909271731v6f1b3492y2246c8ae69a94088@mail.gmail.com> <4AC05319.9070103@erlang-consulting.com> <523869a70909280306y571f147wd4f2569fb8fcacb9@mail.gmail.com> <4AC09256.5090802@erix.ericsson.se> Message-ID: <523869a70909280415w21e4573brff11dc85a06a08ca@mail.gmail.com> Hi again, 2009/9/28 Dan Gudmundsson > > From the README.win32 > => Get and unpack wxWidgets-2.8.9 or higher to /opt/local/pgm inside > cygwin > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Doh! Copying the files now. I'll let you know how it goes. > The configure script only looks there on windows when building with VC++ > We didn't try anything fancy for the windows build there are so few > building > from the source on that platform. > Hope my tutorial/guide can help improve that. At least it shows that it's possible to build erlang with a free (as in beer) toolchain. Thanks for the RTFM. :) :Davide From nesrait@REDACTED Wed Sep 30 01:48:39 2009 From: nesrait@REDACTED (=?ISO-8859-1?Q?Davide_Marqu=EAs?=) Date: Wed, 30 Sep 2009 00:48:39 +0100 Subject: [erlang-patches] Re: Fixes for building erlang under windows In-Reply-To: <523869a70909280306y571f147wd4f2569fb8fcacb9@mail.gmail.com> References: <523869a70909250555h13b355bdn14eadadccb7afb51@mail.gmail.com> <523869a70909271731v6f1b3492y2246c8ae69a94088@mail.gmail.com> <4AC05319.9070103@erlang-consulting.com> <523869a70909280306y571f147wd4f2569fb8fcacb9@mail.gmail.com> Message-ID: <523869a70909291648n46dcb7a1id27768f15503bb22@mail.gmail.com> Hi again, With a bit of help (thanks guys!) I was able to build everything and now have a (hopefully) fully working erlang installation. All the patches and build steps are available here: Building erlang using Visual C++ 2008 Express Edition I'll be doing development on this new system and I'll let you know if anything's broken. Cheers, :Davide From i.am@REDACTED Wed Sep 30 15:06:40 2009 From: i.am@REDACTED (Alex Suraci) Date: Wed, 30 Sep 2009 09:06:40 -0400 Subject: Patch fix for c:nc R13B02-1 Message-ID: <1a3a73650909300606g305b9d18k5d14480f25b391fa@mail.gmail.com> Discussion: http://www.erlang.org/cgi-bin/ezmlm-cgi?2:mss:1525:lhkkmhkfakilgfinpgae Fixes c:nc not working when the source is compiled to an outdir or compiled from anywhere but the cwd. Without this patch, things like `make:all([netload])' (or even just `nc("path/to/file")') are rendered completely useless. They'll compile the file, but not load them as c:nc is almost always looking in the wrong place for the .beam file. -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: cnc.patch Type: application/octet-stream Size: 628 bytes Desc: not available URL: From i.am@REDACTED Wed Sep 30 15:52:34 2009 From: i.am@REDACTED (Alex Suraci) Date: Wed, 30 Sep 2009 09:52:34 -0400 Subject: Patch fix for c:nc R13B02-1 In-Reply-To: <1a3a73650909300606g305b9d18k5d14480f25b391fa@mail.gmail.com> References: <1a3a73650909300606g305b9d18k5d14480f25b391fa@mail.gmail.com> Message-ID: <1a3a73650909300652jfbc38e0s74b97c87ea77c5a8@mail.gmail.com> Actually, that patch is wrong; fixed patch attached. Tested locally this time, works perfectly. On Wed, Sep 30, 2009 at 9:06 AM, Alex Suraci wrote: > Discussion: > ? ?http://www.erlang.org/cgi-bin/ezmlm-cgi?2:mss:1525:lhkkmhkfakilgfinpgae > > Fixes c:nc not working when the source is compiled to an outdir or > compiled from anywhere but the cwd. > > Without this patch, things like `make:all([netload])' (or even just > `nc("path/to/file")') > are rendered completely useless. They'll compile the file, but not load them as > c:nc is almost always looking in the wrong place for the .beam file. > > -- > Alex > -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: cnc.patch Type: application/octet-stream Size: 647 bytes Desc: not available URL: