Missing configure in the repo #2
Comments
|
Opps...just read the wiki: http://wiki.github.com/erlang/otp. I'd suggest updating the README. |
|
Well, there is a reference to that wiki page at the beginning of the README file. |
erlang
pushed a commit
that referenced
this issue
Jun 10, 2011
The core issues this patch attempts to solve is two fold, 1) have release_handler_1 act slightly differently in two corner cases and 2) clean up the code in get_supervised_procs/0 to remove nested cases and etc. Regarding #1, get_supervised_procs/0 will now call functions to test to see if the supervisor is suspended before attempting to ask it for a list of children. This prevents a timeout and VM restart *before* installing the release, thus never upgrading. It now will return an empty list and print an error message allowing the upgrade to proceed. The second corner case is if in a child specification a supervisor is incorrectly stated to be a worker and get_modules is called against it. Again a timeout occurs causing a timeout and VM restart before installing the release. Similar to the last corner case in this patch a empty list is returned and a error message is printed to allow the upgrade to continue. When first looking into the issue it was hard to discover why my upgrades where failing. All I received during the upgrade process was a timeout and a VM restart, no other information. So even if the behavior I described above is unwanted I believe a patch should be included with more descriptive output to help users track down issues like these. Regarding #2, due to the above confusion in trying to figure out what had happened I dug into the code and started tracing it through and found that the nested case statements and etc made it confusing. So I started to rework and clean up, hopefully making this code path clearer to future readers.
erlang
pushed a commit
that referenced
this issue
Jun 22, 2011
The core issues this patch attempts to solve is two fold, 1) have release_handler_1 act slightly differently in two corner cases and 2) clean up the code in get_supervised_procs/0 to remove nested cases and etc. Regarding #1, get_supervised_procs/0 will now call functions to test to see if the supervisor is suspended before attempting to ask it for a list of children. This prevents a timeout and VM restart *before* installing the release, thus never upgrading. It now will return an empty list and print an error message allowing the upgrade to proceed. The second corner case is if in a child specification a supervisor is incorrectly stated to be a worker and get_modules is called against it. Again a timeout occurs causing a timeout and VM restart before installing the release. Similar to the last corner case in this patch a empty list is returned and a error message is printed to allow the upgrade to continue. When first looking into the issue it was hard to discover why my upgrades where failing. All I received during the upgrade process was a timeout and a VM restart, no other information. So even if the behavior I described above is unwanted I believe a patch should be included with more descriptive output to help users track down issues like these. Regarding #2, due to the above confusion in trying to figure out what had happened I dug into the code and started tracing it through and found that the nested case statements and etc made it confusing. So I started to rework and clean up, hopefully making this code path clearer to future readers.
erlang
pushed a commit
that referenced
this issue
Sep 1, 2011
The core issues this patch attempts to solve is two fold, 1) have release_handler_1 act slightly differently in two corner cases and 2) clean up the code in get_supervised_procs/0 to remove nested cases and etc. Regarding #1, get_supervised_procs/0 will now call functions to test to see if the supervisor is suspended before attempting to ask it for a list of children. It now will print an error message regarding the suspended supervisor and produce an error that will cause the VM to restart. Previously it would timeout attempting the call to which_children and the VM would restart without any details regarding the reason. The second corner case is if in a child specification a supervisor is incorrectly stated to be a worker and get_modules is called against it. A timeout will occur causing a VM restart. Similar to the last corner case in this patch an error message is printed and an error is emitted causing a VM restart. When first looking into the issue it was hard to discover why my upgrades where failing. All I received during the upgrade process was a timeout and a VM restart, no other information. This patch should help users track down issues like these. Regarding #2, due to the above confusion in trying to figure out what had happened I dug into the code and started tracing it through and found that the nested case statements and etc made it confusing. So I started to rework and clean up, hopefully making this code path clearer to future readers.
pekadan
pushed a commit
to pekadan/otp
that referenced
this issue
Sep 2, 2011
joewilliams
added a commit
to joewilliams/otp
that referenced
this issue
Sep 5, 2011
The core issues this patch attempts to solve is two fold, 1) have release_handler_1 act slightly differently in two corner cases and 2) clean up the code in get_supervised_procs/0 to remove nested cases and etc. Regarding erlang#1, get_supervised_procs/0 will now call functions to test to see if the supervisor is suspended before attempting to ask it for a list of children. It now will print an error message regarding the suspended supervisor and produce an error that will cause the VM to restart. Previously it would timeout attempting the call to which_children and the VM would restart without any details regarding the reason. The second corner case is if in a child specification a supervisor is incorrectly stated to be a worker and get_modules is called against it. A timeout will occur causing a VM restart. Similar to the last corner case in this patch an error message is printed and an error is emitted causing a VM restart. When first looking into the issue it was hard to discover why my upgrades where failing. All I received during the upgrade process was a timeout and a VM restart, no other information. This patch should help users track down issues like these. Regarding erlang#2, due to the above confusion in trying to figure out what had happened I dug into the code and started tracing it through and found that the nested case statements and etc made it confusing. So I started to rework and clean up, hopefully making this code path clearer to future readers.
erlang
pushed a commit
that referenced
this issue
Sep 6, 2011
The core issues this patch attempts to solve is two fold, 1) have release_handler_1 act slightly differently in two corner cases and 2) clean up the code in get_supervised_procs/0 to remove nested cases and etc. Regarding #1, get_supervised_procs/0 will now call functions to test to see if the supervisor is suspended before attempting to ask it for a list of children. It now will print an error message regarding the suspended supervisor and produce an error that will cause the VM to restart. Previously it would timeout attempting the call to which_children and the VM would restart without any details regarding the reason. The second corner case is if in a child specification a supervisor is incorrectly stated to be a worker and get_modules is called against it. A timeout will occur causing a VM restart. Similar to the last corner case in this patch an error message is printed and an error is emitted causing a VM restart. When first looking into the issue it was hard to discover why my upgrades where failing. All I received during the upgrade process was a timeout and a VM restart, no other information. This patch should help users track down issues like these. Regarding #2, due to the above confusion in trying to figure out what had happened I dug into the code and started tracing it through and found that the nested case statements and etc made it confusing. So I started to rework and clean up, hopefully making this code path clearer to future readers.
pekadan
pushed a commit
to pekadan/otp
that referenced
this issue
Sep 18, 2011
pekadan
pushed a commit
to pekadan/otp
that referenced
this issue
Nov 8, 2011
pekadan
pushed a commit
to pekadan/otp
that referenced
this issue
Nov 11, 2011
pekadan
pushed a commit
to pekadan/otp
that referenced
this issue
Nov 16, 2011
pekadan
pushed a commit
to pekadan/otp
that referenced
this issue
Dec 10, 2011
pekadan
pushed a commit
to pekadan/otp
that referenced
this issue
Jan 18, 2012
- What to do with priv dir names for config funcs? - Should unique names be an option (e.g. -unique_priv_dir)
pekadan
pushed a commit
to pekadan/otp
that referenced
this issue
Mar 2, 2012
pekadan
pushed a commit
to pekadan/otp
that referenced
this issue
Mar 15, 2012
pekadan
pushed a commit
to pekadan/otp
that referenced
this issue
Mar 15, 2012
pekadan
pushed a commit
to pekadan/otp
that referenced
this issue
Mar 16, 2012
pekadan
pushed a commit
to pekadan/otp
that referenced
this issue
Aug 27, 2012
pekadan
pushed a commit
to pekadan/otp
that referenced
this issue
Aug 29, 2012
proxyles
pushed a commit
that referenced
this issue
Oct 5, 2012
This patch fixes a few problems of the SSH shell server that affect the interoperability with SSH clients in widespread use. First problem is that, whenever a channel_request message is received with want_reply=true, the reply ends up being sent to the servers channel id, not the clients channel id. This causes the client to terminate the connection. The easiest solution to the problem appears to be a new function in ssh_connection_manager.erl that translates the servers channel id before sending the reply (in the same manner as other functions do it). Second problem is in ssh_cli.erl. When an SSH client sends a window_change request between PTY allocation and starting the shell (which appears to happen with some clients), ssh_cli.erl crashes because #state.buf is yet 'undefined'. Allocating an empty buffer at PTY allocation time solves the problem. Affected SSH clients: - all clients based on SSH-2.0-TrileadSSH2Java_213 (problem #1) - SSH Term Pro (problem #2)
pekadan
pushed a commit
to pekadan/otp
that referenced
this issue
Oct 29, 2012
pekadan
pushed a commit
to pekadan/otp
that referenced
this issue
Nov 5, 2012
pekadan
pushed a commit
to pekadan/otp
that referenced
this issue
Nov 16, 2012
fdmanana
added a commit
to fdmanana/otp
that referenced
this issue
Dec 28, 2012
When using the async thread pool and compressed files, when
an efile driver port instance is shutdown, the efile_drv
stop callback closes the file descriptor (a gzFile instance
actually) - this is dangerous if at the same time there's
an async thread performing an operation against the file,
for example calling invoke_read(), which can result in a
segmentation fault, or calling invoke_close() which double
closes the gzFile and this in turn causes 2 consecutive calls
to driver_free() against same gzFile instance (resulting in
later unexpected crashes in erl_bestfit_alloc.c for example).
The following test program makes the emulator crash when using
the async thread pool:
-module(t2).
-export([t/1]).
t(N) ->
file:delete("foo.bar"),
% Use of 'compressed' option, for creating/writing the file,
% is irrelevant. It only matters when opening it later for
% reads - a non-compressed file open with the 'compressed'
% option goes through an internal gzFile handle (instead of
% a plain integer fd), just like a compressed file.
%{ok, Fd} = file:open("foo.bar", [raw, write, binary]),
{ok, Fd} = file:open("foo.bar", [raw, write, binary, compressed]),
ok = file:write(Fd, <<"qwerty">>),
ok = file:close(Fd),
Pid = spawn_link(fun() ->
process_flag(trap_exit, true),
loop(N)
end),
Ref = erlang:monitor(process, Pid),
receive
{'DOWN', Ref, _, _, _} ->
ok
end.
loop(0) ->
ok;
loop(N) ->
Server = self(),
Pid = spawn(fun() ->
{ok, Fd} = file:open("foo.bar", [read, raw, binary, compressed]),
Server ! continue,
% Comment the file:read/2 call to make the file:close/1 call much
% more likely to crash or end up causing efile_drv to close twice
% the fd (gzFile), which will make the emulator crash later in the
% best fit allocator (erl_bestfit_alloc.c).
_ = file:read(Fd, 5),
file:close(Fd)
end),
receive continue -> ok end,
exit(Pid, shutdown),
loop(N - 1).
Running this test when using the async thread pool:
shell> erl +A 4
Erlang R15B03 (erts-5.9.3.1) [source] [64-bit] [smp:4:4] [async-threads:4] [hipe] [kernel-poll:false]
Eshell V5.9.3.1 (abort with ^G)
1> c(t2).
{ok,t2}
2> t2:t(500000).
Segmentation fault (core dumped)
When not using the async thread pool, there are no issues:
shell> erl
Erlang R15B03 (erts-5.9.3.1) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]
Eshell V5.9.3.1 (abort with ^G)
1> c(t2).
{ok,t2}
2> t2:t(500000).
ok
3>
An example stack trace when the crash happens because there's
an ongoing read operation is:
Thread 1 (Thread 0x7f021cf2c700 (LWP 10687)):
#0 updatewindow (strm=0x2691bf8, out=5) at zlib/inflate.c:338
erlang#1 0x00000000005a2ba0 in inflate (strm=0x2691bf8, flush=0) at zlib/inflate.c:1141
erlang#2 0x000000000055c46a in erts_gzread (file=0x2691bf8, buf=0x7f0215b29e80, len=5) at drivers/common/gzio.c:523
erlang#3 0x00000000005849ef in invoke_read (data=0x26b2228) at drivers/common/efile_drv.c:1114
erlang#4 0x000000000050adcb in async_main (arg=0x7f021bf5cf40) at beam/erl_async.c:488
erlang#5 0x00000000005c21a0 in thr_wrapper (vtwd=0x7fff69c6ff10) at pthread/ethread.c:106
erlang#6 0x00007f021c573e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
erlang#7 0x00007f021c097cbd in clone () from /lib/x86_64-linux-gnu/libc.so.6
erlang#8 0x0000000000000000 in ?? ()
And when there's an ongoing close operation when the driver
is stopped:
Thread 1 (Thread 0x7fe5f5654700 (LWP 747)):
#0 0x0000000000459b64 in bf_unlink_free_block (block=0x10b2a70, allctr=<optimized out>, flags=<optimized out>) at beam/erl_bestfit_alloc.c:792
erlang#1 bf_unlink_free_block (flags=0, block=0x10b2a70, allctr=0x873380) at beam/erl_bestfit_alloc.c:822
erlang#2 bf_get_free_block (allctr=0x873380, size=<optimized out>, cand_blk=<optimized out>, cand_size=<optimized out>, flags=0) at beam/erl_bestfit_alloc.c:869
erlang#3 0x000000000044f0dd in mbc_alloc_block (alcu_flgsp=<synthetic pointer>, blk_szp=<synthetic pointer>, size=200, allctr=0x873380) at beam/erl_alloc_util.c:1198
erlang#4 mbc_alloc (allctr=0x873380, size=200) at beam/erl_alloc_util.c:1345
erlang#5 0x000000000045449b in do_erts_alcu_alloc (size=200, extra=0x873380, type=165) at beam/erl_alloc_util.c:3442
erlang#6 erts_alcu_alloc_thr_pref (type=165, extra=<optimized out>, size=192) at beam/erl_alloc_util.c:3520
erlang#7 0x000000000055c0bf in gz_open (mode=0x5d98b2 "rb", path=0x1103418 "foo.bar") at drivers/common/gzio.c:164
erlang#8 erts_gzopen (path=0x1103418 "foo.bar", mode=0x5d98b2 "rb") at drivers/common/gzio.c:307
erlang#9 0x0000000000584e47 in invoke_open (data=0x1103330) at drivers/common/efile_drv.c:1857
erlang#10 0x000000000050adcb in async_main (arg=0x7fe5f698af80) at beam/erl_async.c:488
psyeugenic
pushed a commit
to psyeugenic/otp
that referenced
this issue
Jan 23, 2013
When using the async thread pool and compressed files, when
an efile driver port instance is shutdown, the efile_drv
stop callback closes the file descriptor (a gzFile instance
actually) - this is dangerous if at the same time there's
an async thread performing an operation against the file,
for example calling invoke_read(), which can result in a
segmentation fault, or calling invoke_close() which double
closes the gzFile and this in turn causes 2 consecutive calls
to driver_free() against same gzFile instance (resulting in
later unexpected crashes in erl_bestfit_alloc.c for example).
The following test program makes the emulator crash when using
the async thread pool:
-module(t2).
-export([t/1]).
t(N) ->
file:delete("foo.bar"),
% Use of 'compressed' option, for creating/writing the file,
% is irrelevant. It only matters when opening it later for
% reads - a non-compressed file open with the 'compressed'
% option goes through an internal gzFile handle (instead of
% a plain integer fd), just like a compressed file.
%{ok, Fd} = file:open("foo.bar", [raw, write, binary]),
{ok, Fd} = file:open("foo.bar", [raw, write, binary, compressed]),
ok = file:write(Fd, <<"qwerty">>),
ok = file:close(Fd),
Pid = spawn_link(fun() ->
process_flag(trap_exit, true),
loop(N)
end),
Ref = erlang:monitor(process, Pid),
receive
{'DOWN', Ref, _, _, _} ->
ok
end.
loop(0) ->
ok;
loop(N) ->
Server = self(),
Pid = spawn(fun() ->
{ok, Fd} = file:open("foo.bar", [read, raw, binary, compressed]),
Server ! continue,
% Comment the file:read/2 call to make the file:close/1 call much
% more likely to crash or end up causing efile_drv to close twice
% the fd (gzFile), which will make the emulator crash later in the
% best fit allocator (erl_bestfit_alloc.c).
_ = file:read(Fd, 5),
file:close(Fd)
end),
receive continue -> ok end,
exit(Pid, shutdown),
loop(N - 1).
Running this test when using the async thread pool:
shell> erl +A 4
Erlang R15B03 (erts-5.9.3.1) [source] [64-bit] [smp:4:4] [async-threads:4] [hipe] [kernel-poll:false]
Eshell V5.9.3.1 (abort with ^G)
1> c(t2).
{ok,t2}
2> t2:t(500000).
Segmentation fault (core dumped)
When not using the async thread pool, there are no issues:
shell> erl
Erlang R15B03 (erts-5.9.3.1) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]
Eshell V5.9.3.1 (abort with ^G)
1> c(t2).
{ok,t2}
2> t2:t(500000).
ok
3>
An example stack trace when the crash happens because there's
an ongoing read operation is:
Thread 1 (Thread 0x7f021cf2c700 (LWP 10687)):
#0 updatewindow (strm=0x2691bf8, out=5) at zlib/inflate.c:338
erlang#1 0x00000000005a2ba0 in inflate (strm=0x2691bf8, flush=0) at zlib/inflate.c:1141
erlang#2 0x000000000055c46a in erts_gzread (file=0x2691bf8, buf=0x7f0215b29e80, len=5) at drivers/common/gzio.c:523
erlang#3 0x00000000005849ef in invoke_read (data=0x26b2228) at drivers/common/efile_drv.c:1114
erlang#4 0x000000000050adcb in async_main (arg=0x7f021bf5cf40) at beam/erl_async.c:488
erlang#5 0x00000000005c21a0 in thr_wrapper (vtwd=0x7fff69c6ff10) at pthread/ethread.c:106
erlang#6 0x00007f021c573e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
erlang#7 0x00007f021c097cbd in clone () from /lib/x86_64-linux-gnu/libc.so.6
erlang#8 0x0000000000000000 in ?? ()
And when there's an ongoing close operation when the driver
is stopped:
Thread 1 (Thread 0x7fe5f5654700 (LWP 747)):
#0 0x0000000000459b64 in bf_unlink_free_block (block=0x10b2a70, allctr=<optimized out>, flags=<optimized out>) at beam/erl_bestfit_alloc.c:792
erlang#1 bf_unlink_free_block (flags=0, block=0x10b2a70, allctr=0x873380) at beam/erl_bestfit_alloc.c:822
erlang#2 bf_get_free_block (allctr=0x873380, size=<optimized out>, cand_blk=<optimized out>, cand_size=<optimized out>, flags=0) at beam/erl_bestfit_alloc.c:869
erlang#3 0x000000000044f0dd in mbc_alloc_block (alcu_flgsp=<synthetic pointer>, blk_szp=<synthetic pointer>, size=200, allctr=0x873380) at beam/erl_alloc_util.c:1198
erlang#4 mbc_alloc (allctr=0x873380, size=200) at beam/erl_alloc_util.c:1345
erlang#5 0x000000000045449b in do_erts_alcu_alloc (size=200, extra=0x873380, type=165) at beam/erl_alloc_util.c:3442
erlang#6 erts_alcu_alloc_thr_pref (type=165, extra=<optimized out>, size=192) at beam/erl_alloc_util.c:3520
erlang#7 0x000000000055c0bf in gz_open (mode=0x5d98b2 "rb", path=0x1103418 "foo.bar") at drivers/common/gzio.c:164
erlang#8 erts_gzopen (path=0x1103418 "foo.bar", mode=0x5d98b2 "rb") at drivers/common/gzio.c:307
erlang#9 0x0000000000584e47 in invoke_open (data=0x1103330) at drivers/common/efile_drv.c:1857
erlang#10 0x000000000050adcb in async_main (arg=0x7fe5f698af80) at beam/erl_async.c:488
pekadan
pushed a commit
to pekadan/otp
that referenced
this issue
Mar 18, 2013
pekadan
pushed a commit
to pekadan/otp
that referenced
this issue
Apr 10, 2013
nox
referenced
this issue
in nox/otp
May 5, 2013
When an error isn't caught by a catch expression, the VM sends the faulty stacktrace as a string with a small message to the error logger. As it is already a string representation and not the stacktrace itself, the result may as well be readable and human-friendly. Example: 1> spawn(fun () -> (fun () -> 1 + foo end)(), 42 end). =ERROR REPORT==== 5-May-2013::15:28:15 === Error in process <0.45.0> with exit value: badarith #1 erlang:'+'(1, foo) <BIF> #2 erl_eval:do_apply/6 ["erl_eval.erl":573] #3 erl_eval:exprs/5 ["erl_eval.erl":118]
garazdawi
pushed a commit
to gearnode/otp
that referenced
this issue
Feb 10, 2021
…ge-update2 Add libwxgtk-webview3.0-gtk3-dev to base images erlang#2
This was referenced Feb 10, 2021
RaimoNiskanen
pushed a commit
to RaimoNiskanen/otp
that referenced
this issue
Feb 12, 2021
found with OpenSSL built with address-sanitizer:
ERROR: AddressSanitizer: global-buffer-overflow on address 0x7f848de3b5c4 ...
READ of size 4 at 0x7f848de3b5c4 thread T9 (6_scheduler)
#0 0x7f848fed28ea in engine_table_register crypto/engine/eng_table.c:97
erlang#1 0x7f848fd83dac in ENGINE_register_digests crypto/engine/tb_digest.c:30
erlang#2 0x7f848fd201d1 in engine_register_nif otp/lib/crypto/c_src/engine.c:447
erlang#3 0x556fe2e15de4 in process_main x86_64-unknown-linux-gnu/asan/emu/beam_cold.h:177
erlang#4 0x556fe2db96e7 in sched_thread_func beam/erl_process.c:8496
erlang#5 0x556fe346bd1b in thr_wrapper pthread/ethread.c:122
erlang#6 0x7f8498b886da in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76da)
erlang#7 0x7f84988b171e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x12171e)
0x7f848de3b5c4 is located 0 bytes to the right of global variable 'test_digest_ids'
defined in 'otp_test_engine.c:199:12' (0x7f848de3b5c0) of size 4
leoliu
pushed a commit
to leoliu/otp
that referenced
this issue
Feb 22, 2021
and robustify the NIFs against faulty usage.
* Add ctx->is_functional to know if ENGINE_init has been called
and if ENGINE_finish needs to be called.
* Add cleanup to destructor as fallback if engine_free/finish_nif
has not been called.
* Set ctx->engine=NULL when freed
and check it after all calls to enif_get_resource.
Removed memory leaks reported by address-sanitizer:
Test case engine_SUITE:ctrl_cmd_string
Direct leak of 192 byte(s) in 1 object(s) allocated from:
#0 0x7f955fb64b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
erlang#1 0x7f9556c0accb in CRYPTO_malloc crypto/mem.c:222
erlang#2 0x7f9556c0acfe in CRYPTO_zalloc crypto/mem.c:230
erlang#3 0x7f9556bd227e in ENGINE_new crypto/engine/eng_lib.c:34
erlang#4 0x7f9556bd345c in ENGINE_by_id crypto/engine/eng_list.c:301
erlang#5 0x7f9556fc1965 in engine_by_id_nif otp/lib/crypto/c_src/engine.c:138
erlang#6 0x562b780d4e8a in process_main x86_64-unknown-linux-gnu/asan/smp/beam_cold.h:184
erlang#7 0x562b7810f1eb in sched_thread_func beam/erl_process.c:8486
erlang#8 0x562b787a1b9b in thr_wrapper pthread/ethread.c:122
erlang#9 0x7f955f0a26da in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76da)
ferd
added a commit
to ferd/otp
that referenced
this issue
Sep 20, 2021
sverker
added a commit
that referenced
this issue
Mar 15, 2024
The second big commit for OTP 27.0-rc2 Cleanup of all trace settings when trace session is destroyed. Current API additions are S = erlang:trace_session_create(Name, Tracer, []) erlang:trace_session_destroy(S) erlang:trace(S, _, _, _) erlang:trace_pattern(S, _, _, _) erlang:trace_info(S, _, _) erlang:trace_session_info(_)
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The configure scripts are missing in the git repo. Looking at the source bundle on erlang.org:
$ find otp_src_R13B02-1 -name "configure"
otp_src_R13B02-1/configure
otp_src_R13B02-1/erts/configure
otp_src_R13B02-1/lib/common_test/configure
otp_src_R13B02-1/lib/configure
otp_src_R13B02-1/lib/erl_interface/configure
otp_src_R13B02-1/lib/gs/configure
otp_src_R13B02-1/lib/megaco/configure
otp_src_R13B02-1/lib/odbc/configure
otp_src_R13B02-1/lib/snmp/configure
otp_src_R13B02-1/lib/test_server/src/configure
otp_src_R13B02-1/lib/wx/configure
$git log
commit 84adefa
Author: Erlang/OTP [email protected]
Date: Fri Nov 20 14:54:40 2009 +0000
The README files says to execute ./configure. If there is another step to generate these, please let me know.
The text was updated successfully, but these errors were encountered: