From richardc@REDACTED Thu Feb 1 13:03:09 2007 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 01 Feb 2007 13:03:09 +0100 Subject: [erlang-bugs] [erlang-questions] edoc problem in R11B-3 In-Reply-To: References: Message-ID: <45C1D6FD.9010602@it.uu.se> Eric Merritt wrote: > I am getting the following error when running edoc. > > edoc: error in layout 'edoc_layout': > {'EXIT',{badarg,[{erlang,binary_to_list,[{head,[[10],{title,[[77,111,100|...]]},[10],{link,[{rel,...},{...}|...],[]},[10]]}]},{xmerl_lib,export_text,2},{xmerl_lib,export_text,2},{xmerl,apply_cb,5},{xmerl,export_content,2},{xmerl,export_element,2},{xmerl,export_content,2},{xmerl,export1,3}]}}. > edoc: error in doclet 'edoc_doclet': {'EXIT',error}. > > edoc seems to always output the above error. It doesn't seem to matter > what source its run on or how edoc is called. Is anyone else having a > similar problem, if so, have you been able to work around it? The problem is that someone has broken the xmerl_lib:expand_content/4 function, in some misguided attempt to make it accept non-lists as content, even though the documentation states that content must be flat lists, and there is even a comment in the code that explains why this must be so (hint: strings are also lists, and may be deep). Revert to the previous version of xmerl (or edit expand_content/4 to match the previous version if you prefer that), and you should be ok. The following comment in the release notes, made me worried as soon as I saw it: OTP-6099 Bug in xmerl removed so that simple syntax element content is exported correctly. How about reading the spec before deciding to "fix" something? /Richard PS. "Do not meddle in the affairs of Wizards, for they are subtle and quick to anger." From hpjcon@REDACTED Thu Feb 1 18:25:34 2007 From: hpjcon@REDACTED (Jan Jacobs) Date: Thu, 1 Feb 2007 19:25:34 +0200 Subject: [erlang-bugs] ODBC and Windows 2003 Anomaly References: <000c01c7424f$b491c490$c800a8c0@jan03> Message-ID: <003201c74625$fccc7320$c800a8c0@jan03> Hi All, Installed Erlang 5.5.3 Runtime. It is working !!! Thanks Jan Jacobs ----- Original Message ----- From: Jan Jacobs To: erlang-bugs@REDACTED Sent: Saturday, January 27, 2007 10:14 PM Subject: [erlang-bugs] ODBC and Windows 2003 Anomaly Hi All, I am experiencing an anomaly with erlang running the odbc application. Steps: I start the odbc application. >application:start(odbc). Create a odbc connection to the databse. It works an the queries work. >f(Ref),{ok,Ref}=odbc:connect("DSN=example;UID=SYSDBA;PWD=masterkey",[]). Disconnect from the databse. >odbc:disconnect(Ref). Create a new connection. The erlang runtime hangs and the erlang process CPU runs away. >f(Ref),{ok,Ref}=odbc:connect("DSN=example;UID=SYSDBA;PWD=masterkey",[]). System Description: - Microsoft Windows Server 2003, Standard Edition and Service Pack 1. - Erlang 5.5.2 Summary: The weirdest thing I have an application the follows the same steps as above which works every time on Windows XP. From 10 Windows 2003 servers I have experience the problem three times already. I am not sure if I am missing something. Any help will be appreciated. Thanks Jan Jacobs ------------------------------------------------------------------------------ _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://www.erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf.wiger@REDACTED Fri Feb 2 16:45:08 2007 From: ulf.wiger@REDACTED (Ulf Wiger (TN/EAB)) Date: Fri, 2 Feb 2007 16:45:08 +0100 Subject: [erlang-bugs] erlc help text Message-ID: <6616D98C65DD514BA2E1DDC5F9223155E27D51@esealmw115.eemea.ericsson.se> >From erlc -help: -pa path add path to the front of Erlang's code path -pa path add path to the end of Erlang's code path The second line should obviously be -pz path add path to the end of Erlang's code path >From what I could tell, the -pz flag was supported already in R9C (perhaps earlier), but wasn't added to the help text until R10B-4, and then misspelled from the beginning. BR, Ulf W -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon@REDACTED Fri Feb 2 18:19:38 2007 From: jon@REDACTED (Jon Olsson) Date: Fri, 2 Feb 2007 18:19:38 +0100 Subject: [erlang-bugs] Erlang/OTP R11B-3 OpenBSD patches Message-ID: <20070202171938.GD17703@gonzo.vexed.se> Hi, I sent these patches earlier to patches@, but they didn't reach the mailing list so I'm reposting them to erlang-bugs@REDACTED All patches are against R11B-3. / Jon This fixes a bug on OpenBSD/sparc64 build - this needs to be conditionalized for OpenBSD if these are the right flags for other sparc64 OS'en. --- erts/emulator/Makefile.in.orig Mon Jan 29 13:52:09 2007 +++ erts/emulator/Makefile.in Wed Jan 31 17:25:33 2007 @@ -137,7 +137,7 @@ darwinCFLAGS=-DDARWIN noopsysCFLAGS= OPSYSCFLAGS=$($(OPSYS)CFLAGS) ARCH=@ARCH@ -ultrasparcCFLAGS=-Wa,-xarch=v8plusa +ultrasparcCFLAGS= ARCHCFLAGS=$($(ARCH)CFLAGS) ifdef HIPE_ENABLED This fixes a hang in the configure script on OpenBSD/amd64 similiar to the FreeBSD one. --- erts/configure.in.orig Wed Jan 31 17:36:19 2007 +++ erts/configure.in Wed Jan 31 17:37:08 2007 @@ -1855,14 +1855,14 @@ static __inline__ int check_fpe(double f #endif -#if (defined(__linux__) && (defined(__i386__) || defined(__x86_64__) || defined(__sparc__) || defined( __powerpc__)) ) || (defined(__DARWIN__) && (defined(__i386__) || defined(__ppc__))) || (defined(__FreeBSD__) && (defi ned(__i386__) || defined(__x86_64__))) || (defined(__sun__) && defined(__x86_64__)) +#if (defined(__linux__) && (defined(__i386__) || defined(__x86_64__) || defined(__sparc__) || defined( __powerpc__)) ) || (defined(__DARWIN__) && (defined(__i386__) || defined(__ppc__))) || ((defined(__OpenBSD__) || defi ned(__FreeBSD __)) && (defined(__i386__) || defined(__x86_64__))) || (defined(__sun__) && defined(__x86_64__)) #if defined(__linux__) && defined(__i386__) #include #elif defined(__FreeBSD__) && defined(__i386__) #include #include -#elif defined(__FreeBSD__) && defined(__x86_64__) +#elif (defined(__OpenBSD__) || defined(__FreeBSD__)) && defined(__x86_64__) #include #include #endif ----- End forwarded message ----- -- Jon From mikpe@REDACTED Fri Feb 2 19:29:55 2007 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 2 Feb 2007 19:29:55 +0100 (MET) Subject: [erlang-bugs] Erlang/OTP R11B-3 OpenBSD patches Message-ID: <200702021829.l12ITtDB013434@harpo.it.uu.se> On Fri, 2 Feb 2007 18:19:38 +0100, Jon Olsson wrote: >Hi, I sent these patches earlier to patches@, but they didn't reach the >mailing list so I'm reposting them to erlang-bugs@REDACTED > >All patches are against R11B-3. > >/ Jon > >This fixes a bug on OpenBSD/sparc64 build - this needs to be conditionalized for >OpenBSD if these are the right flags for other sparc64 OS'en. >--- erts/emulator/Makefile.in.orig Mon Jan 29 13:52:09 2007 >+++ erts/emulator/Makefile.in Wed Jan 31 17:25:33 2007 >@@ -137,7 +137,7 @@ darwinCFLAGS=-DDARWIN > noopsysCFLAGS= > OPSYSCFLAGS=$($(OPSYS)CFLAGS) > ARCH=@ARCH@ >-ultrasparcCFLAGS=-Wa,-xarch=v8plusa >+ultrasparcCFLAGS= > ARCHCFLAGS=$($(ARCH)CFLAGS) > > ifdef HIPE_ENABLED They were introduced originally for Solaris, but they also see use (whether needed or not) on Linux. They are (were) needed on Solaris because the compilers do not necessarily support the SPARC v9 instruction set by default, and parts of the runtime system need(ed) to include v9 instructions. What exactly is the failure on OpenBSD? >This fixes a hang in the configure script on OpenBSD/amd64 similiar to the FreeBSD one. >--- erts/configure.in.orig Wed Jan 31 17:36:19 2007 >+++ erts/configure.in Wed Jan 31 17:37:08 2007 >@@ -1855,14 +1855,14 @@ static __inline__ int check_fpe(double f > > #endif > >-#if (defined(__linux__) && (defined(__i386__) || defined(__x86_64__) || defined(__sparc__) || defined( >__powerpc__)) >) || (defined(__DARWIN__) && (defined(__i386__) || defined(__ppc__))) || (defined(__FreeBSD__) && (defi >ned(__i386__) > || defined(__x86_64__))) || (defined(__sun__) && defined(__x86_64__)) >+#if (defined(__linux__) && (defined(__i386__) || defined(__x86_64__) || defined(__sparc__) || defined( >__powerpc__)) >) || (defined(__DARWIN__) && (defined(__i386__) || defined(__ppc__))) || ((defined(__OpenBSD__) || defi >ned(__FreeBSD >__)) && (defined(__i386__) || defined(__x86_64__))) || (defined(__sun__) && defined(__x86_64__)) > > #if defined(__linux__) && defined(__i386__) > #include > #elif defined(__FreeBSD__) && defined(__i386__) > #include > #include >-#elif defined(__FreeBSD__) && defined(__x86_64__) >+#elif (defined(__OpenBSD__) || defined(__FreeBSD__)) && defined(__x86_64__) > #include > #include > #endif This patch is broken due word-wrapping. But what it implies is that OpenBSD should receive the same treatment as FreeBSD wrt floating-point exceptions and SIGFPE handlers, correct? A (perhaps temporary) shell account on an x86-32 and an x86-64 OpenBSD box would do wonders for Erlang/OTP's OpenBSD support. (That's how the FreeBSD folks got their verified support for HiPE, floating-point exceptions, and SMP. Hint hint, nudge nudge.) /Mikael From jon@REDACTED Sat Feb 3 09:10:33 2007 From: jon@REDACTED (Jon Olsson) Date: Sat, 3 Feb 2007 09:10:33 +0100 Subject: [erlang-bugs] Erlang/OTP R11B-3 OpenBSD patches In-Reply-To: <200702021829.l12ITtDB013434@harpo.it.uu.se> References: <200702021829.l12ITtDB013434@harpo.it.uu.se> Message-ID: <20070203081033.GA16318@gonzo.vexed.se> On Fri, Feb 02, 2007 at 07:29:55PM +0100, Mikael Pettersson wrote: > On Fri, 2 Feb 2007 18:19:38 +0100, Jon Olsson wrote: [snip] > They were introduced originally for Solaris, but they > also see use (whether needed or not) on Linux. > They are (were) needed on Solaris because the compilers do not > necessarily support the SPARC v9 instruction set by default, > and parts of the runtime system need(ed) to include v9 instructions. > > What exactly is the failure on OpenBSD? cc -O2 -pipe -I/usr/ports/lang/erlang/w-erlang-11b.2/otp_src_R11B-2/erts/sparc64-unknown-openbsd4.0 -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -Wa,-xarch=v8plusa -Ibeam -Isys/unix -Isys/common -Isparc64-unknown-openbsd4.0/opt/plain -Isparc64-unknown-openbsd4.0 -Izlib -Ihipe -I../include/internal -I../include/internal/sparc64-unknown-openbsd4.0 -c hipe/hipe_mkliterals.c -o obj/sparc64-unknown-openbsd4.0/opt/plain/hipe_mkliterals.o {standard input}: Assembler messages: {standard input}:286: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:289: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:293: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:841: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:844: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:848: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:856: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:857: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:858: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:859: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:864: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:865: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:867: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:869: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:874: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:885: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:887: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:895: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:898: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:915: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:916: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:920: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:939: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:940: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:944: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:959: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:961: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:966: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:972: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:984: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:985: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:990: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1026: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:1028: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:1032: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1036: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:1038: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:1041: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1043: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:1044: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:1045: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:1046: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:1049: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1057: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:1060: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:1062: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1066: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1070: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:1085: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:1086: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:1090: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1105: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:1107: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:1112: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1118: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:1153 reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:1155: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:1159: Error: internal error: can't port reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1162: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:1164: Error: internal error: canype 92 (`BFD_RELOC_SPARC_M44') {standard input}:1168: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1171: Error: internal error: can't export rec type 91 (`BFD_RELOC_SPARC_H44') {standard input}:1173: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:1178: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1179: Eror: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:1181: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:118 Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1185: Error: internal error: can'ttandard input}:1192: Error: internal error: can't export reloc pe 91 (`BFD_RELOC_SPARC_H44') {standard input}:1193: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:1194: Error: internal error: can't export relype 92 (`BFD_RELOC_SPARC_M44') {standard input}:1197: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1200: Error: internal error: can't export re type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1201: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:1202: Error: internal error: can't export loc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:1203: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:1204: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:1207:ror: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1210: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:121rror: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:1216: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:12: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1222: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}4: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:1227: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1228: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:1230: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard :1235: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1255: Error: internal error:t reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:1326: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SRC_L44') {standard input}:1333: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1334: Error: internal error: can't export reloc type 91 (`BFD_RELOPARC_H44') {standard input}:1337: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:1339: Error: internal error: can't export reloc type 93 (`BFD_RE_SPARC_L44') {standard input}:1343: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') {standard input}:1344: Error: internal error: can't export reloc type 91 (`BFD_LOC_SPARC_H44') {standard input}:1346: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') {standard input}:1347: Error: internal error: can't export reloc type 92 (`BELOC_SPARC_M44') {standard input}:1350: Error: internal error: n't export reloc type 93 (`BFD_RELOC_SPARC_L44') {standard input}:1351: Error: internal error: can't export reloc type 93 (`BFC_SPARC_L44') {standard input}:1361: Fatal error: {standard inp}:523: bad return from bfd_install_relocation: 4 gmake[2]: *** [obj/sparc64-unknown-openbsd4.0/opt/plain/hipe_mkliterals.o] Error 1 gmake[2]: Leaving directory `/usr/ports/lang/erlang/w-erlb.2/otp_src_R11B-2/erts/emulator' gmake[1]: *** [generate] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/erlang/w-erlan11b.2/otp_src_R11B-2/erts/emulator' gmake: *** [depend] Error 2 [snip word wrapped patch] > This patch is broken due word-wrapping. But what it implies is > that OpenBSD should receive the same treatment as FreeBSD wrt > floating-point exceptions and SIGFPE handlers, correct? Correct, adding the patches as attachement now, sorry about the copy'n'pasto. > A (perhaps temporary) shell account on an x86-32 and an x86-64 > OpenBSD box would do wonders for Erlang/OTP's OpenBSD support. > (That's how the FreeBSD folks got their verified support for HiPE, > floating-point exceptions, and SMP. Hint hint, nudge nudge.) My x86-32 OpenBSD box could possibly be used for that, although it is dog slow so, it won't be pleasant using it. -- Jon -------------- next part -------------- This fixes a bug on OpenBSD/sparc64 --- erts/emulator/Makefile.in.orig Mon Jan 29 13:52:09 2007 +++ erts/emulator/Makefile.in Wed Jan 31 17:25:33 2007 @@ -137,7 +137,7 @@ darwinCFLAGS=-DDARWIN noopsysCFLAGS= OPSYSCFLAGS=$($(OPSYS)CFLAGS) ARCH=@ARCH@ -ultrasparcCFLAGS=-Wa,-xarch=v8plusa +ultrasparcCFLAGS= ARCHCFLAGS=$($(ARCH)CFLAGS) ifdef HIPE_ENABLED This fixes hangs in the configure script on OpenBSD/amd64 --- erts/configure.in.orig Wed Jan 31 17:36:19 2007 +++ erts/configure.in Wed Jan 31 17:37:08 2007 @@ -1855,14 +1855,14 @@ static __inline__ int check_fpe(double f #endif -#if (defined(__linux__) && (defined(__i386__) || defined(__x86_64__) || defined(__sparc__) || defined(__powerpc__)) ) || (defined(__DARWIN__) && (defined(__i386__) || defined(__ppc__))) || (defined(__FreeBSD__) && (defined(__i386__) || defined(__x86_64__))) || (defined(__sun__) && defined(__x86_64__)) +#if (defined(__linux__) && (defined(__i386__) || defined(__x86_64__) || defined(__sparc__) || defined(__powerpc__)) ) || (defined(__DARWIN__) && (defined(__i386__) || defined(__ppc__))) || ((defined(__OpenBSD__) || defined(__FreeBSD __)) && (defined(__i386__) || defined(__x86_64__))) || (defined(__sun__) && defined(__x86_64__)) #if defined(__linux__) && defined(__i386__) #include #elif defined(__FreeBSD__) && defined(__i386__) #include #include -#elif defined(__FreeBSD__) && defined(__x86_64__) +#elif (defined(__OpenBSD__) || defined(__FreeBSD__)) && defined(__x86_64__) #include #include #endif From mikpe@REDACTED Sat Feb 3 12:40:53 2007 From: mikpe@REDACTED (Mikael Pettersson) Date: Sat, 3 Feb 2007 12:40:53 +0100 (MET) Subject: [erlang-bugs] Erlang/OTP R11B-3 OpenBSD patches Message-ID: <200702031140.l13BerLZ023497@harpo.it.uu.se> On Sat, 3 Feb 2007 09:10:33 +0100, Jon Olsson wrote: > > They were introduced originally for Solaris, but they > > also see use (whether needed or not) on Linux. > > They are (were) needed on Solaris because the compilers do not > > necessarily support the SPARC v9 instruction set by default, > > and parts of the runtime system need(ed) to include v9 instructions. > > > > What exactly is the failure on OpenBSD? > > cc -O2 -pipe -I/usr/ports/lang/erlang/w-erlang-11b.2/otp_src_R11B-2/erts/sparc64-unknown-openbsd4.0 -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -Wa,-xarch=v8plusa -Ibeam -Isys/unix -Isys/common -Isparc64-unknown-openbsd4.0/opt/plain -Isparc64-unknown-openbsd4.0 -Izlib -Ihipe -I../include/internal -I../include/internal/sparc64-unknown-openbsd4.0 -c hipe/hipe_mkliterals.c -o obj/sparc64-unknown-openbsd4.0/opt/plain/hipe_mkliterals.o > {standard input}: Assembler messages: > {standard input}:286: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') > {standard input}:289: Error: internal error: can't export reloc type 92 (`BFD_RELOC_SPARC_M44') > {standard input}:293: Error: internal error: can't export reloc type 93 (`BFD_RELOC_SPARC_L44') > {standard input}:841: Error: internal error: can't export reloc type 91 (`BFD_RELOC_SPARC_H44') etc That smells like a toolchain (binutils/gas) bug. It certainly works with the versions I have on my Aurora Linux SPARC64 machine. Hmm, does your `cc' perhaps default to building 64-bit code? The v8plusa option should not be needed in that case, and might even be harmful. > This fixes a bug on OpenBSD/sparc64 > --- erts/emulator/Makefile.in.orig Mon Jan 29 13:52:09 2007 > +++ erts/emulator/Makefile.in Wed Jan 31 17:25:33 2007 > @@ -137,7 +137,7 @@ darwinCFLAGS=-DDARWIN > noopsysCFLAGS= > OPSYSCFLAGS=$($(OPSYS)CFLAGS) > ARCH=@ARCH@ > -ultrasparcCFLAGS=-Wa,-xarch=v8plusa > +ultrasparcCFLAGS= > ARCHCFLAGS=$($(ARCH)CFLAGS) Unfortunately this change breaks Solaris/SPARC: gcc -g -O3 -fomit-frame-pointer -I/tmp/mikpe/otp-0202/erts/sparc-sun-solaris2.9 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DHYBRID -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Ibeam -Isys/unix -Isys/common -Isparc-sun-solaris2.9/opt/hybrid -Isparc-sun-solaris2.9 -Izlib -Ihipe -I../include/internal -I../include/internal/sparc-sun-solaris2.9 -c beam/io.c -o obj/sparc-sun-solaris2.9/opt/hybrid/io.o beam/io.c: In function 'io_list_to_vec': beam/io.c:922: warning: pointer targets in assignment differ in signedness beam/io.c: In function 'deliver_vec_message': beam/io.c:1735: warning: pointer targets in assignment differ in signedness /usr/ccs/bin/as: "/tmp/ccJaaCzj.s", line 1599: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: "/tmp/ccJaaCzj.s", line 1611: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: "/tmp/ccJaaCzj.s", line 1617: error: cannot use v8plus instructions in a non-v8plus target binary (many more of these follow) The issue is that we MUST use V9 instructions for atomic operations, but the assembler rejects them unless the v8plusa option is passed to it. This means that you need to figure out how to make this change only for OpenBSD. An update in erts/configure{.in,} to detect OpenBSD and set OPSYS accordingly, plus some trickery in erts/emulator/Makefile.in, should suffice. /Mikael From jon@REDACTED Sun Feb 4 23:03:34 2007 From: jon@REDACTED (Jon Olsson) Date: Sun, 4 Feb 2007 23:03:34 +0100 Subject: [erlang-bugs] Erlang/OTP R11B-3 OpenBSD patches In-Reply-To: <200702031140.l13BerLZ023497@harpo.it.uu.se> References: <200702031140.l13BerLZ023497@harpo.it.uu.se> Message-ID: <20070204220334.GC16318@gonzo.vexed.se> On Sat, Feb 03, 2007 at 12:40:53PM +0100, Mikael Pettersson wrote: > Hmm, does your `cc' perhaps default to building 64-bit code? The v8plusa option should > not be needed in that case, and might even be harmful. It seems to be the case that OpenBSD/sparc64 gcc generates 64-bit code. % gcc foo.c % file a.out a.out: ELF 64-bit MSB executable, Sparc64, version 1, for OpenBSD, dynamically linked (uses shared libs), not stripped > The issue is that we MUST use V9 instructions for atomic operations, but the assembler > rejects them unless the v8plusa option is passed to it. > > This means that you need to figure out how to make this change only for OpenBSD. > An update in erts/configure{.in,} to detect OpenBSD and set OPSYS accordingly, > plus some trickery in erts/emulator/Makefile.in, should suffice. Ok, I'll cook something up later this week perhaps. -- Jon From bjorn@REDACTED Mon Feb 5 08:24:00 2007 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 05 Feb 2007 08:24:00 +0100 Subject: [erlang-bugs] erlc help text In-Reply-To: <6616D98C65DD514BA2E1DDC5F9223155E27D51@esealmw115.eemea.ericsson.se> References: <6616D98C65DD514BA2E1DDC5F9223155E27D51@esealmw115.eemea.ericsson.se> Message-ID: Thanks! Will be corrected in R11B-4. /Bjorn "Ulf Wiger \(TN/EAB\)" writes: > >From erlc -help: > > -pa path add path to the front of Erlang's code path > -pa path add path to the end of Erlang's code path > > > The second line should obviously be > > -pz path add path to the end of Erlang's code path > > >From what I could tell, the -pz flag was supported already > in R9C (perhaps earlier), but wasn't added to the help > text until R10B-4, and then misspelled from the beginning. > > > BR, > Ulf W > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From ulf@REDACTED Wed Feb 7 21:58:06 2007 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 07 Feb 2007 21:58:06 +0100 Subject: [erlang-bugs] erl_syntax_lib:vann_try_expr/2 Message-ID: I started using erl_syntax_lib:annotate_bindings/2 and found that it doesn't work too well. The problem seems to lie here: vann_cond_expr(_Tree, _Env) -> erlang:error({not_implemented,cond_expr}). vann_try_expr(_Tree, _Env) -> erlang:error({not_implemented,try_expr}). I doesn't bother me much that cond_expr isn't handled, since the parser doesn't handle it either, but the lack of support for try expressions _is_ a bit troublesome. Am I right in assuming that this was simply forgotten? (: BR, Ulf W -- Ulf Wiger From richardc@REDACTED Wed Feb 7 22:11:52 2007 From: richardc@REDACTED (Richard Carlsson) Date: Wed, 07 Feb 2007 22:11:52 +0100 Subject: [erlang-bugs] erl_syntax_lib:vann_try_expr/2 In-Reply-To: References: Message-ID: <45CA4098.5090400@it.uu.se> Ulf Wiger wrote: > I started using erl_syntax_lib:annotate_bindings/2 > and found that it doesn't work too well. > [...] > I doesn't bother me much that cond_expr isn't > handled, since the parser doesn't handle it either, > but the lack of support for try expressions _is_ > a bit troublesome. > > Am I right in assuming that this was simply forgotten? (: Well, I've probably not touched that module since way before the work on try-expressions was finished. Apparently, that code has not seen a lot of exercise. I'll put it on my todo-list, but if you want it fixed faster, I suggest you implement it and submit a patch. I have way too little time these days for all the things that I'd like to do. /Richard From john.hughes@REDACTED Sat Feb 10 14:45:02 2007 From: john.hughes@REDACTED (John Hughes) Date: Sat, 10 Feb 2007 14:45:02 +0100 Subject: [erlang-bugs] Erlang shell hangs Message-ID: <001201c74d19$ac792490$0301a8c0@JOHNSTABLET> Start the Erlang shell from the command line. Type Io:format("~p~n",[lists:seq(1,8000)]). The shell hangs. It's not consuming CPU, just hanging. This behaviour depends on the shell state. Start the shell and type the TWO commands Io:format("~p~n",[lists:seq(1,7000)]). Io:format("~p~n",[lists:seq(1,8000)]). and BOTH commands work. That's why it's important to run the first command in a freshly started shell, to reproduce the bug. Perhaps something to do with dynamically expanding the process heap? I'm using a fresh download of R11B-3 under Windows XP, but the bug has been there at least since version 5.4.12 of the shell. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon@REDACTED Mon Feb 12 10:41:31 2007 From: jon@REDACTED (Jon Olsson) Date: Mon, 12 Feb 2007 10:41:31 +0100 Subject: [erlang-bugs] Erlang/OTP R11B-3 OpenBSD patches In-Reply-To: <20070204220334.GC16318@gonzo.vexed.se> References: <200702031140.l13BerLZ023497@harpo.it.uu.se> <20070204220334.GC16318@gonzo.vexed.se> Message-ID: <20070212094131.GA22528@gonzo.vexed.se> On Sun, Feb 04, 2007 at 11:03:34PM +0100, Jon Olsson wrote: > Ok, I'll cook something up later this week perhaps. Here's an updated patch, I'm also including the diff for the amd64 floating point exceptions issue. erts/configure.in | 5 +++-- erts/emulator/Makefile.in | 5 +++++ 2 files changed, 8 insertions(+), 2 deletions(-) -------------- next part -------------- $OpenBSD: patch-erts_configure_in,v 1.1 2007/02/03 11:48:39 steven Exp $ --- erts/configure.in.orig Mon Jan 29 13:53:26 2007 +++ erts/configure.in Sun Feb 11 22:42:06 2007 @@ -304,6 +304,7 @@ SunOS) case `uname -r` in Linux) OPSYS=linux;; Darwin) OPSYS=darwin;; FreeBSD) OPSYS=freebsd;; +OpenBSD) OPSYS=openbsd;; esac ARCH=noarch case `uname -m` in @@ -1855,14 +1856,14 @@ static __inline__ int check_fpe(double f #endif -#if (defined(__linux__) && (defined(__i386__) || defined(__x86_64__) || defined(__sparc__) || defined(__powerpc__))) || (defined(__DARWIN__) && (defined(__i386__) || defined(__ppc__))) || (defined(__FreeBSD__) && (defined(__i386__) || defined(__x86_64__))) || (defined(__sun__) && defined(__x86_64__)) +#if (defined(__linux__) && (defined(__i386__) || defined(__x86_64__) || defined(__sparc__) || defined(__powerpc__))) || (defined(__DARWIN__) && (defined(__i386__) || defined(__ppc__))) || ((defined(__OpenBSD__) || defined(__FreeBSD__)) && (defined(__i386__) || defined(__x86_64__))) || (defined(__sun__) && defined(__x86_64__)) #if defined(__linux__) && defined(__i386__) #include #elif defined(__FreeBSD__) && defined(__i386__) #include #include -#elif defined(__FreeBSD__) && defined(__x86_64__) +#elif (defined(__OpenBSD__) || defined(__FreeBSD__)) && defined(__x86_64__) #include #include #endif --- erts/emulator/Makefile.in.orig Mon Jan 29 13:52:09 2007 +++ erts/emulator/Makefile.in Sun Feb 11 22:38:23 2007 @@ -137,7 +137,12 @@ darwinCFLAGS=-DDARWIN noopsysCFLAGS= OPSYSCFLAGS=$($(OPSYS)CFLAGS) ARCH=@ARCH@ + +ifeq ($(OPSYS),openbsd) +ultrasparcCFLAGS= +else ultrasparcCFLAGS=-Wa,-xarch=v8plusa +endif ARCHCFLAGS=$($(ARCH)CFLAGS) ifdef HIPE_ENABLED From mikpe@REDACTED Thu Feb 15 16:52:16 2007 From: mikpe@REDACTED (Mikael Pettersson) Date: Thu, 15 Feb 2007 16:52:16 +0100 Subject: [erlang-bugs] Erlang/OTP R11B-3 OpenBSD patches In-Reply-To: <20070212094131.GA22528@gonzo.vexed.se> References: <200702031140.l13BerLZ023497@harpo.it.uu.se> <20070204220334.GC16318@gonzo.vexed.se> <20070212094131.GA22528@gonzo.vexed.se> Message-ID: <17876.33200.935940.252279@alkaid.it.uu.se> Jon Olsson writes: > On Sun, Feb 04, 2007 at 11:03:34PM +0100, Jon Olsson wrote: > > Ok, I'll cook something up later this week perhaps. > > Here's an updated patch, I'm also including the diff for the amd64 > floating point exceptions issue. > > erts/configure.in | 5 +++-- > erts/emulator/Makefile.in | 5 +++++ > 2 files changed, 8 insertions(+), 2 deletions(-) > > $OpenBSD: patch-erts_configure_in,v 1.1 2007/02/03 11:48:39 steven Exp $ > --- erts/configure.in.orig Mon Jan 29 13:53:26 2007 > +++ erts/configure.in Sun Feb 11 22:42:06 2007 > @@ -304,6 +304,7 @@ SunOS) case `uname -r` in > Linux) OPSYS=linux;; > Darwin) OPSYS=darwin;; > FreeBSD) OPSYS=freebsd;; > +OpenBSD) OPSYS=openbsd;; > esac > ARCH=noarch > case `uname -m` in ... > --- erts/emulator/Makefile.in.orig Mon Jan 29 13:52:09 2007 > +++ erts/emulator/Makefile.in Sun Feb 11 22:38:23 2007 > @@ -137,7 +137,12 @@ darwinCFLAGS=-DDARWIN > noopsysCFLAGS= > OPSYSCFLAGS=$($(OPSYS)CFLAGS) > ARCH=@ARCH@ > + > +ifeq ($(OPSYS),openbsd) > +ultrasparcCFLAGS= > +else > ultrasparcCFLAGS=-Wa,-xarch=v8plusa > +endif > ARCHCFLAGS=$($(ARCH)CFLAGS) While this may solve your immediate problem (64-bit mode code on OpenBSD/SPARC64), it's inappropriate for other cases: What if the user prefers to generate 32-bit code on OpenBSD? What about other operating systems on SPARC64? I've checked in the patch below which solves the problem by using ARCH=sparc64 instead of ARCH=ultrasparc when the C compiler generates 64-bit mode code. This is similar to the solution I used for x86 machines where `uname` alone is insufficient to detect if the system will be built in 32- or 64-bit mode. This patch was required to let me build a 64-bit system on an Ultra running Linux. /Mikael --- otp-0202/erts/configure.in.~1~ 2006-11-24 13:51:40.000000000 +0100 +++ otp-0202/erts/configure.in 2007-02-14 19:55:02.000000000 +0100 @@ -308,7 +308,7 @@ esac ARCH=noarch case `uname -m` in sun4u) ARCH=ultrasparc;; -sparc64) ARCH=ultrasparc;; +sparc64) ARCH=sparc64;; sun4v) ARCH=ultrasparc;; i86pc) ARCH=x86;; i386) ARCH=x86;; @@ -327,6 +327,7 @@ esac dnl dnl Convert between x86 and amd64 based on the compiler's mode. +dnl Ditto between ultrasparc and sparc64. dnl AC_MSG_CHECKING(whether compilation mode forces ARCH adjustment) case "$ARCH-$ac_cv_sizeof_void_p" in @@ -338,6 +339,14 @@ amd64-4) AC_MSG_RESULT(yes: adjusting ARCH=amd64 to ARCH=x86) ARCH=x86 ;; +ultrasparc-8) + AC_MSG_RESULT(yes: adjusting ARCH=ultrasparc to ARCH=sparc64) + ARCH=amd64 + ;; +sparc64-4) + AC_MSG_RESULT(yes: adjusting ARCH=sparc64 to ARCH=ultrasparc) + ARCH=x86 + ;; *) AC_MSG_RESULT(no) ;; --- otp-0202/erts/configure.~1~ 2006-11-24 13:51:40.000000000 +0100 +++ otp-0202/erts/configure 2007-02-14 19:58:28.000000000 +0100 @@ -1423,7 +1423,7 @@ esac ARCH=noarch case `uname -m` in sun4u) ARCH=ultrasparc;; -sparc64) ARCH=ultrasparc;; +sparc64) ARCH=sparc64;; sun4v) ARCH=ultrasparc;; i86pc) ARCH=x86;; i386) ARCH=x86;; @@ -1451,6 +1451,14 @@ amd64-4) echo "$ac_t""yes: adjusting ARCH=amd64 to ARCH=x86" 1>&6 ARCH=x86 ;; +ultrasparc-8) + echo "$ac_t""yes: adjusting ARCH=ultrasparc to ARCH=sparc64" 1>&6 + ARCH=amd64 + ;; +sparc64-4) + echo "$ac_t""yes: adjusting ARCH=sparc64 to ARCH=ultrasparc" 1>&6 + ARCH=x86 + ;; *) echo "$ac_t""no" 1>&6 ;; From jon@REDACTED Thu Feb 15 17:12:29 2007 From: jon@REDACTED (Jon Olsson) Date: Thu, 15 Feb 2007 17:12:29 +0100 Subject: [erlang-bugs] Erlang/OTP R11B-3 OpenBSD patches In-Reply-To: <17876.33200.935940.252279@alkaid.it.uu.se> References: <200702031140.l13BerLZ023497@harpo.it.uu.se> <20070204220334.GC16318@gonzo.vexed.se> <20070212094131.GA22528@gonzo.vexed.se> <17876.33200.935940.252279@alkaid.it.uu.se> Message-ID: <20070215161229.GA1821@gonzo.vexed.se> On Thu, Feb 15, 2007 at 04:52:16PM +0100, Mikael Pettersson wrote: [snip] > While this may solve your immediate problem (64-bit mode code > on OpenBSD/SPARC64), it's inappropriate for other cases: What > if the user prefers to generate 32-bit code on OpenBSD? What > about other operating systems on SPARC64? For the record: core% uname -a OpenBSD xxx.yyy.com 4.0 GENERIC#999 sparc64 core% gcc -m32 z.c cc1: error: -m32 is not supported by this configuration I guess this means OpenBSD doesn't support 32 bit code compilation on sparc64? Correct me if I'm wrong. Cheers, -- Jon From mikpe@REDACTED Thu Feb 15 17:30:34 2007 From: mikpe@REDACTED (Mikael Pettersson) Date: Thu, 15 Feb 2007 17:30:34 +0100 Subject: [erlang-bugs] Erlang/OTP R11B-3 OpenBSD patches In-Reply-To: <20070215161229.GA1821@gonzo.vexed.se> References: <200702031140.l13BerLZ023497@harpo.it.uu.se> <20070204220334.GC16318@gonzo.vexed.se> <20070212094131.GA22528@gonzo.vexed.se> <17876.33200.935940.252279@alkaid.it.uu.se> <20070215161229.GA1821@gonzo.vexed.se> Message-ID: <17876.35498.695590.428324@alkaid.it.uu.se> Jon Olsson writes: > On Thu, Feb 15, 2007 at 04:52:16PM +0100, Mikael Pettersson wrote: > [snip] > > While this may solve your immediate problem (64-bit mode code > > on OpenBSD/SPARC64), it's inappropriate for other cases: What > > if the user prefers to generate 32-bit code on OpenBSD? What > > about other operating systems on SPARC64? > > For the record: > > core% uname -a > OpenBSD xxx.yyy.com 4.0 GENERIC#999 sparc64 > core% gcc -m32 z.c > cc1: error: -m32 is not supported by this configuration > > I guess this means OpenBSD doesn't support 32 bit code compilation > on sparc64? Correct me if I'm wrong. Well, this particular gcc cannot generate 32-bit mode code. But that's an exception: gcc is usually configured as a "bi-arch" compiler that can generate either 32-bit or 64-bit code, and many 64-bit systems make 32-bit code the default. It's certainly possible that OpenBSD on SPARC64 has completely banned all 32-bit mode code, making your change OK for OpenBSD. But even if they have done that, inferring 64-bitness from the C compiler instead of `uname` is a safer and more general solution. /Mikael From jon@REDACTED Thu Feb 15 19:59:13 2007 From: jon@REDACTED (Jon Olsson) Date: Thu, 15 Feb 2007 19:59:13 +0100 Subject: [erlang-bugs] Erlang/OTP R11B-3 OpenBSD patches In-Reply-To: <17876.35498.695590.428324@alkaid.it.uu.se> References: <200702031140.l13BerLZ023497@harpo.it.uu.se> <20070204220334.GC16318@gonzo.vexed.se> <20070212094131.GA22528@gonzo.vexed.se> <17876.33200.935940.252279@alkaid.it.uu.se> <20070215161229.GA1821@gonzo.vexed.se> <17876.35498.695590.428324@alkaid.it.uu.se> Message-ID: <20070215185913.GB1821@gonzo.vexed.se> On Thu, Feb 15, 2007 at 05:30:34PM +0100, Mikael Pettersson wrote: > Jon Olsson writes: > > On Thu, Feb 15, 2007 at 04:52:16PM +0100, Mikael Pettersson wrote: > > [snip] > > > While this may solve your immediate problem (64-bit mode code > > > on OpenBSD/SPARC64), it's inappropriate for other cases: What > > > if the user prefers to generate 32-bit code on OpenBSD? What > > > about other operating systems on SPARC64? > > > > For the record: > > > > core% uname -a > > OpenBSD xxx.yyy.com 4.0 GENERIC#999 sparc64 > > core% gcc -m32 z.c > > cc1: error: -m32 is not supported by this configuration > > > > I guess this means OpenBSD doesn't support 32 bit code compilation > > on sparc64? Correct me if I'm wrong. > > Well, this particular gcc cannot generate 32-bit mode code. > But that's an exception: gcc is usually configured as a > "bi-arch" compiler that can generate either 32-bit or 64-bit > code, and many 64-bit systems make 32-bit code the default. > > It's certainly possible that OpenBSD on SPARC64 has completely > banned all 32-bit mode code, making your change OK for OpenBSD. > But even if they have done that, inferring 64-bitness from the > C compiler instead of `uname` is a safer and more general solution. I wasn't disagreeing with your changes/comment regarding sparc64 in general, just stating the "OpenBSD world order". Cheers, -- Jon From denis.bilenko@REDACTED Thu Feb 22 11:16:16 2007 From: denis.bilenko@REDACTED (Denis Bilenko) Date: Thu, 22 Feb 2007 16:16:16 +0600 Subject: [erlang-bugs] Unexpected badarg from io:format Message-ID: <95d6e98c0702220216x12787f6cv4168e17d7c1775cb@mail.gmail.com> Hello, I've run into a problem with io:format, it exits with these arguments: (emacs@REDACTED)190> io:format("~w~p", ["xxxxxxxxxxxxxxxxxxx", <<1>>]). ** exited: {badarg,[{io,format, [<0.27.0>,"~w~p",["xxxxxxxxxxxxxxxxxxx",<<1>>]]}, {erl_eval,do_apply,5}, {shell,exprs,6}, {shell,eval_loop,3}]} ** Contents of string doesn't matter, but length does. erl -version: Erlang (ASYNC_THREADS) (BEAM) emulator version 5.5.3 From bengt.kleberg@REDACTED Thu Feb 22 14:10:14 2007 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 22 Feb 2007 14:10:14 +0100 Subject: [erlang-bugs] Unexpected badarg from io:format In-Reply-To: <95d6e98c0702220216x12787f6cv4168e17d7c1775cb@mail.gmail.com> References: <95d6e98c0702220216x12787f6cv4168e17d7c1775cb@mail.gmail.com> Message-ID: <45DD9636.7000805@ericsson.com> On 2007-02-22 11:16, Denis Bilenko wrote: > Hello, > > I've run into a problem with io:format, it exits with these arguments: > > (emacs@REDACTED)190> io:format("~w~p", ["xxxxxxxxxxxxxxxxxxx", <<1>>]). > ** exited: {badarg,[{io,format, > [<0.27.0>,"~w~p",["xxxxxxxxxxxxxxxxxxx",<<1>>]]}, > {erl_eval,do_apply,5}, not reproducible. i get: io:format("~w~p", ["xxxxxxxxxxxxxxxxxxx", <<1>>]). [120,120,120,120,120,120,120,120,120,120,120,120,120,120,120,120,120,120,120]<<1>>ok Erlang (ASYNC_THREADS,HIPE) (BEAM) emulator version 5.5.3 SunOS ws67042 5.8 Generic_117350-39 sun4u sparc SUNW,Sun-Blade-1500 bengt -- Those were the days... EPO guidelines 1978: "If the contribution to the known art resides solely in a computer program then the subject matter is not patentable in whatever manner it may be presented in the claims." From hans.bolinder@REDACTED Thu Feb 22 14:28:23 2007 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Thu, 22 Feb 2007 14:28:23 +0100 Subject: [erlang-bugs] Unexpected badarg from io:format In-Reply-To: <95d6e98c0702220216x12787f6cv4168e17d7c1775cb@mail.gmail.com> References: <95d6e98c0702220216x12787f6cv4168e17d7c1775cb@mail.gmail.com> Message-ID: <17885.39543.201666.150367@gargle.gargle.HOWL> [Denis Bilenko:] > I've run into a problem with io:format, it exits with these arguments: > > (emacs@REDACTED)190> io:format("~w~p", ["xxxxxxxxxxxxxxxxxxx", <<1>>]). > ** exited: {badarg,[{io,format, > [<0.27.0>,"~w~p",["xxxxxxxxxxxxxxxxxxx",<<1>>]]}, > {erl_eval,do_apply,5}, > {shell,exprs,6}, > {shell,eval_loop,3}]} ** > > Contents of string doesn't matter, but length does. Thanks for the bug report. The following patch should solve the problem. Best regards, Hans Bolinder, Erlang/OTP *** /usr/local/otp/releases/otp_beam_solaris8_r11b_patched/lib/stdlib-1.14.3/src/io_lib_pretty.erl Tue Jan 30 13:55:48 2007 --- io_lib_pretty.erl Thu Feb 22 13:55:27 2007 *************** *** 159,165 **** %% Reuse the list created by io_lib:write_binary()... pp_binary([LT,LT,S,GT,GT], Col, Ll, Ind, LD) -> N = max(8, Ll - Col - LD), ! [LT,LT,pp_binary(S, N, N, Ind),GT,GT]. pp_binary([BS, $, | S], N, N0, Ind) -> Len = length(BS) + 1, --- 159,167 ---- %% Reuse the list created by io_lib:write_binary()... pp_binary([LT,LT,S,GT,GT], Col, Ll, Ind, LD) -> N = max(8, Ll - Col - LD), ! [LT,LT,pp_binary(S, N, N, Ind),GT,GT]; ! pp_binary(S, _Col, _Ll, _Ind, _LD) -> ! S. pp_binary([BS, $, | S], N, N0, Ind) -> Len = length(BS) + 1, From maik.hentsche@REDACTED Thu Feb 22 16:16:48 2007 From: maik.hentsche@REDACTED (Maik Hentsche) Date: Thu, 22 Feb 2007 16:16:48 +0100 Subject: [erlang-bugs] Compiling otp_src_R11B-2 fails on OpenSuSE 10.2 Message-ID: <20070222161648.31ce3452@siegfried.osrc.amd.com> Hi, I tried to compile erlang from http://www.erlang.org/download.html and it failed with the following error: obj/x86_64-unknown-linux-gnu/opt/hybrid/hipe_x86_signal.o: In function `my_sigaction': /home/mhentsc3/Download/jabber/otp_src_R11B-2/erts/emulator/hipe/hipe_x86_signal.c:220: undefined reference to `INIT' /home/mhentsc3/Download/jabber/otp_src_R11B-2/erts/emulator/hipe/hipe_x86_signal.c:230: undefined reference to `__next_sigaction' obj/x86_64-unknown-linux-gnu/opt/hybrid/hipe_x86_signal.o: In function `hipe_signal_init': /home/mhentsc3/Download/jabber/otp_src_R11B-2/erts/emulator/hipe/hipe_x86_signal.c:305: undefined reference to `INIT' obj/x86_64-unknown-linux-gnu/opt/hybrid/hipe_x86_signal.o: In function `my_sigaction': /home/mhentsc3/Download/jabber/otp_src_R11B-2/erts/emulator/hipe/hipe_x86_signal.c:220: undefined reference to `INIT' /home/mhentsc3/Download/jabber/otp_src_R11B-2/erts/emulator/hipe/hipe_x86_signal.c:230: undefined reference to `__next_sigaction' /home/mhentsc3/Download/jabber/otp_src_R11B-2/erts/emulator/hipe/hipe_x86_signal.c:220: undefined reference to `INIT' /home/mhentsc3/Download/jabber/otp_src_R11B-2/erts/emulator/hipe/hipe_x86_signal.c:230: undefined reference to `__next_sigaction' collect2: ld returned 1 exit status make[3]: *** [/home/mhentsc3/Download/jabber/otp_src_R11B-2/bin/x86_64-unknown-linux-gnu/beam.hybrid] Error 1 make[3]: Leaving directory `/home/mhentsc3/Download/jabber/otp_src_R11B-2/erts/emulator' make[2]: *** [opt] Error 2 make[2]: Leaving directory `/home/mhentsc3/Download/jabber/otp_src_R11B-2/erts/emulator' make[1]: *** [hybrid] Error 2 make[1]: Leaving directory `/home/mhentsc3/Download/jabber/otp_src_R11B-2/erts' make: *** [emulator] Error 2 The Compiler is used is this: Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --program-suffix=-4.1 --enable-version-specific-runtime-libs --without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux Thread model: posix gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) so long Maik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mikpe@REDACTED Thu Feb 22 17:05:28 2007 From: mikpe@REDACTED (Mikael Pettersson) Date: Thu, 22 Feb 2007 17:05:28 +0100 (MET) Subject: [erlang-bugs] Compiling otp_src_R11B-2 fails on OpenSuSE 10.2 Message-ID: <200702221605.l1MG5StS018059@harpo.it.uu.se> On Thu, 22 Feb 2007 16:16:48 +0100, Maik Hentsche wrote: > I tried to compile erlang from http://www.erlang.org/download.html and > it failed with the following error: > obj/x86_64-unknown-linux-gnu/opt/hybrid/hipe_x86_signal.o: In function > `my_sigaction': /home/mhentsc3/Download/jabber/otp_src_R11B-2/erts/emulator= > /hipe/hipe_x86_signal.c:220: > undefined reference to > `INIT' /home/mhentsc3/Download/jabber/otp_src_R11B-2/erts/emulator/hipe/hip= > e_x86_signal.c:230: > undefined reference to `__next_sigaction' > obj/x86_64-unknown-linux-gnu/opt/hybrid/hipe_x86_signal.o: In function > `hipe_signal_init': /home/mhentsc3/Download/jabber/otp_src_R11B-2/erts/emul= > ator/hipe/hipe_x86_signal.c:305: > undefined reference to `INIT' etc Probably related to you having a relatively new glibc. An update to R11B-3 should fix this. /Mikael From maik.hentsche@REDACTED Fri Feb 23 08:52:57 2007 From: maik.hentsche@REDACTED (Maik Hentsche) Date: Fri, 23 Feb 2007 08:52:57 +0100 Subject: [erlang-bugs] Compiling otp_src_R11B-2 fails on OpenSuSE 10.2 In-Reply-To: <200702221605.l1MG5StS018059@harpo.it.uu.se> References: <200702221605.l1MG5StS018059@harpo.it.uu.se> Message-ID: <20070223085257.3f362bd5@siegfried.osrc.amd.com> "Mikael Pettersson" wrote: > Probably related to you having a relatively new glibc. > An update to R11B-3 should fix this. Indeed, the problem vanished with R11B-3. Thank you for your help. so long Maik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ulf@REDACTED Mon Feb 26 08:32:42 2007 From: ulf@REDACTED (Ulf Wiger) Date: Mon, 26 Feb 2007 08:32:42 +0100 Subject: [erlang-bugs] efficiency guide Message-ID: In the Efficiency Guide, http://www.erlang.org/doc/doc-5.5.3/doc/efficiency_guide/tablesDatabases.html#4.1.4 it says: "Even the cheapest Mnesia operations, dirty_write operations," Dirty_write operations are not the cheapest Mnesia operations. For example, mnesia:activity(ets, fun() -> mnesia:write(Obj) end) is significantly cheaper than mnesia:dirty_write(Obj) (and also semantically different, of course...) BR, Ulf W -- Ulf Wiger From goryachev@REDACTED Tue Feb 27 15:43:04 2007 From: goryachev@REDACTED (Igor Goryachev) Date: Tue, 27 Feb 2007 17:43:04 +0300 Subject: [erlang-bugs] http client bug while getting zero-length response Message-ID: <87vehnbr0n.fsf@yandex-team.ru> Hello everyone. I've just found a bug in inets http-client (or somewhere in chunk decode routines). It is reproduced when a remote http-server sends zero-length response: goryachev@REDACTED:~% erl Erlang (BEAM) emulator version 5.5.3 [source] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.5.3 (abort with ^G) 1> http:request(get, {"http://www.goryachev.org/", []}, [], []). =INFO REPORT==== 27-Feb-2007::17:04:20 === The inets application was not started. Has now been started as a temporary application. {error,session_remotly_closed} 2> =ERROR REPORT==== 27-Feb-2007::17:05:36 === ** Generic server <0.41.0> terminating ** Last message in was {tcp_closed,#Port<0.114>} ** When Server state == {state, {request, #Ref<0.0.0.68>, <0.29.0>, 0, http, {"www.goryachev.org",80}, "/", [], get, {http_request_h, undefined, "keep-alive", undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, "www.goryachev.org", undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, [], undefined, undefined, undefined, undefined, "0", undefined, undefined, undefined, undefined, undefined, undefined, []}, {[],[]}, {http_options,infinity,true,[],undefined,false}, "http://www.goryachev.org/", [], none, []}, {tcp_session, {{"www.goryachev.org",80},<0.41.0>}, false, http, #Port<0.114>, 1}, {"HTTP/1.1",200,"OK"}, {http_response_h, undefined, "keep-alive", "Tue, 27 Feb 2007 14:03:13 GMT", undefined, undefined, "chunked", undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, "nginx/0.5.11", "Accept-Encoding, Cookie", undefined, undefined, undefined, undefined, "-1", undefined, undefined, undefined, "text/html; charset=utf-8", undefined, undefined, []}, undefined, {http_chunk, decode_data, [0, <<"\r\n">>, {nolimit, <<>>, 0, nolimit, {200, {request, #Ref<0.0.0.68>, <0.29.0>, 0, http, {"www.goryachev.org",80}, "/", [], get, {http_request_h, undefined, "keep-alive", undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, "www.goryachev.org", undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, [], undefined, undefined, undefined, undefined, "0", undefined, undefined, undefined, undefined, undefined, undefined, []}, {[],[]}, {http_options,infinity,true,[],undefined,false}, "http://www.goryachev.org/", [], none, []}}}]}, {[],[]}, new, [], nolimit, nolimit, {options,{undefined,[]},0,2,2,disabled,enabled,false}, {timers,[],undefined}} ** Reason for termination == ** session_remotly_closed This behaviour could be worked around using timeout param (i.e. {timeout, 10000}). -- Igor Goryachev Yandex development team.