Re: tmpfile leaks

[Ken Raeburn]

On Jul 29, 2011, at 12:04, Chris K. Jester-Young wrote:
> On Fri, Jul 29, 2011 at 09:07:43AM +0200, Andy Wingo wrote:
>> What should we do here?
> 
> There's two ways I can think of:
> 
> 1. Basically reimplement the functionality of tmpfile, using mkstemp
>   and unlink, passing the fd to scm_fdes_to_port as before. This does
>   require reimplementing the TMPDIR lookup stuff (since that doesn't
>   seem to be exposed by libc).
> 
> 2. Use tmpfile as before, dup the file descriptor, and close the stdio
>   stream unconditionally. This is wasteful of a file stream in that
>   one gets created only to be immediately destroyed, but it's more
>   faithful to the system-provided tmpfile, quirks and all.

Better check whether these will work on Windows, where file deletion interacts 
differently than on UNIX.

Ken

Re: GUILE_CFLAGS contains warning options

[Ken Raeburn]

On Feb 20, 2011, at 17:50, Bruno Haible wrote:
> For the PTHREAD_CFLAGS it is more tricky: On most platforms you can use
> "-lpthread" instead of "-pthread", and all compilers support -l options.
> But on OSF/1, the options for using threads are compiler dependent:
>  * -pthread for cc,
>  * -lpthread for gcc.

There are other platforms where compiling for thread support changes more than 
just adding a library.  For example, in NetBSD 5.0, it looks like stdio.h 
defines getc() in a non-thread-safe way if _REENTRANT and _PTHREADS (which get 
defined by "gcc -pthread") are not defined.  So even with gcc, just replacing 
"-pthread" with "-lpthread" isn't good enough.

Ken

Re: Missing and out-of-date information in guile.1, the Guile man page

[Ken Raeburn]

On Jan 16, 2011, at 14:38, Mark Harig wrote:
>> 
>> I'd say too OS-dependent; or more to do with how guile should be
>> properly installed, than how to use it once it is installed.
>> 
>> But on the other hand, I might be misunderstanding what you had in 
> mind;
>> if you'd like to propose some specific text...
>> 
> 
> If a user has followed the instructions in the section "Obtaining and
> Installing Guile", and installed guile in the "/usr/local/" directory
> tree, then, on systems that use the dynamic linker/loader ld.so or
> ld-linux.so*, the instructions in the section "Linking Guile into
> Programs" will fail because the new program 'simple-guile' will not be
> able to locate the shared library 'libguile-2.0.so*'.

I think the right answer for that is not to tell people that they have to set 
environment variables in order to run Guile programs, but to tell developers 
how to link programs properly so that they find the library at run time.  This 
tends to be somewhat platform-dependent, but often arguments like "-R" or 
"-rpath" are needed; libtool should just Do The Right Thing, if it's used.  I'm 
less familiar with pkg-config, but expect it should be have similarly.  In 
fact, the man page for pkg-config on my system (Mac OS X with MacPorts 
installed) says the "--libs-only-L" option "prints the -L/-R part" of the link 
options, which suggests to me that pkg-config is indeed supposed to be printing 
options to set the run-time load path.  If it's not doing that for you, then we 
should figure out why not.

In short, don't document how to work around a bug, if you can just fix the bug. 
:-)

Ken

Re: [bug #29574] VM stack overflows aren't properly handled [1.9.10]

[Ken Raeburn]

On May 22, 2010, at 11:55, Ludovic Courtès wrote:
>>> Please reply through the bug tracker
>>> .  The patch is there.
>> 
>> I never doubted the presence of the patch, I was only a bit miffed as I
>> work best offline.
> 
> Oh right.

If savannah's bug tracker doesn't have a useful offline mode, make sure you 
file a bug report. :-)

The ability to fetch the desired subset of the database (or the whole thing, if 
it's not huge) with rsync or some such tool, and view it through emacs or a 
local debbugs web server is probably adequate

Ken

Re: Mac OS X .dylib not working

[Ken Raeburn]

[Is Hans on one of these lists now?  His original message to bug-guile said not 
and asked to be cc'ed.]

On Feb 2, 2010, at 13:01, Ludovic Courtès wrote:
> The Guile manually specifically tells that FNAME should not contain an
> extension.

That could be unfortunate, since it means that unlike other Mac applications, a 
Guile application would not be able to customize its plugin names to use 
Foo.quuxplugin type names.  Guile apps would be limited to a hardcoded set of 
suffixes then, right?

> Surprisingly, I just noticed that Guile itself doesn’t use the ‘-module’
> option of Libtool when creating its ‘libguile-srfi-srfi-1’ module (which
> is meant to be dlopened *or* directly linked against), although this has
> never caused any problems on OS X.  If you search for that in [1],
> ‘libguile-srfi-srfi-1’ is actually created with ‘-dynamiclib’.

Current versions of Mac OS X can load shared libraries (.dylib) as well as the 
bundle format that seems to have been the original plugin form (.so, .bundle, 
...).  So in practice, assuming you can dlopen and dlclose a shared library 
works pretty well, though I gather it might not have worked as well in earlier 
releases.  But we should also support the format(s) intended for plugin modules 
as well, and the naming conventions (which appear to be somewhat varied, and 
less consistent than on other OSes).

At least, that's my impression; I'm not an expert in that area of the OS, I've 
just read some of the docs...

Ken

Re: Mac OS X .dylib not working

[Ken Raeburn]

On Feb 2, 2010, at 04:08, Hans Aberg wrote:
On 2 Feb 2010, at 07:42, Ralf Wildenhues wrote:
> 
>>> On Mac OS X (trying it on 10.5.8 PPC G4), guile-1.8.7 cannot open
>>> dynamic library files with name extensions .dylib, but only if they
>>> are renamed using .so instead. On the Bug-Guile list they say it
>>> just calls libltdl, in the libtool package. I have installed latest
>>> of both, but the problem persists:
>> 
>> libtool should produce modules named *.so on Darwin if you pass the
>> -module flag at link time.  Typically, -avoid-version is used for
>> modules as well.
> 
> 
> But dlopen() on Mac OS X can only open files in the native format, which 
> isn't ELF, and they are typically named with the .dylib file name extension. 
> If it finds a .so file on ELF format, all it does is reporting it cannot be 
> opened.

".so" doesn't mean ELF format, and on some systems including Mac OS X, 
"dynamically linked shared library" (e.g., a ".dylib" file) is not the same as 
"dynamically loadable object".  Did you not see my earlier email to you and the 
bug-guile list?

Ken

Re: Mac OS X .dylib

[Ken Raeburn]

On Jan 30, 2010, at 09:41, Hans Aberg wrote:

[I'm not on this list, so please cc me.]

It seems guile-1.8.7 does not admit dynamic library file name  
extensions .dylib, but only .so, on Mac OS X (tried 10.5.8. PPC G4),  
despite the manual saying guile should adapt to local standards. The  
example in the manual sec. 4.2.1 works fine with

 gcc -dynamiclib -lguile -o libguile-bessel.so bessel.c
but not if changed to libguile-bessel.dylib, giving the error within  
guile:
 standard input:2:1: file: "libguile-bessel", message: "file not  
found"


The Mac OS X situation is a bit more complicated than on "normal" ELF- 
based UNIX systems; shared libraries and dynamically loadable objects  
are not the same thing.  It's easy to assume they're equivalent when  
working mostly on ELF or Windows systems where .so or .dll files work  
for both, but it's not always true.  GNU libtool even has options for  
creating loadable modules as distinct from regular shared libraries.


See for example http://www.finkproject.org/doc/porting/porting.en.html#shared.lib-and-mod 
 for one brief discussion of shared libraries versus "bundles" on the  
Mac, and how the ".so" suffix is often used for loadable objects by  
convention in ported UNIX software (not just in fink, but in the OS: / 
usr/lib/pam/*.so, /usr/lib/sasl2/*.so), though I see a lot of  
".bundle" names on my system too.  Further confusing the matter:


 * The term "bundle" seems to be used in Apple documentation both for  
a particular type of file generated by the linker for loadable objects  
-- the linker has different flags for them vs shared libraries -- and  
a directory structure used for distributing a collection of files as  
an application, framework, or plugin.


 * The modern dlopen implementation on the Mac (it wasn't there at  
all in 10.0) seems capable of loading both "bundles" (the file version  
I think) and regular Mac shared libraries.  In 10.4, dlclose()  
couldn't unload a dynamic library but could unload a bundle; in 10.5,  
it can unload both.  So it's unclear how relevant the distinction  
between "loadable objects" and "shared libraries" is any more, at  
least if you're targeting 10.5 or 10.6 as your minimum required OS  
version.  One distinction I haven't (yet) seen mentioned as having  
gone away is that bundles can reference symbols from the main  
application, but dynamic libraries cannot.


See also http://lists.apple.com/archives/darwin-dev/2008/Dec/msg00045.html 
 ...


http://developer.apple.com/Mac/library/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html 
 describes the Mach-O file types, and says ".bundle" is the  
conventional suffix for plugins.


So, in short, one could argue that looking only for ".so" for  
dynamically loadable objects *is* conforming to (one set of) standards  
for the Mac, annoying though it may be.


On Mac OS X, it should probably look for .dylib first, and  
perhaps .so for backwards compatibility.


I think perhaps it should try without a suffix (in case the  
application code specifies it), then both of these and maybe also  
".bundle", though I don't have a strong sense which order they should  
be tried in.


Ken

Re: [PATCH] Declare `GC_dump' ourselves if doesn't.

[Ken Raeburn]

On Jan 9, 2010, at 17:30, Andy Wingo wrote:

On Sat 09 Jan 2010 14:28, Thien-Thi Nguyen  writes:


+# `GC_dump' is available in GC 6.8 but not declared.


Neil, you also compile with pre-7.x, no? Do we need to support this?

Just wondering if it wouldn't be easier to simply require 7.x without
workarounds. It seems debian is the sticker here..


Given how much everyone seems to keep saying that you should really  
use 7.x, I think it would be a good idea for configure and/or some  
file including  to check the version (if possible), and  
reject 6.x.  Unless guile *will* work reliably with 6.8, in which case  
people should stop saying such things. :-)


Ken

P.S.  I'd offer to write up a patch, but I'm in that annoying in- 
between state of having a new job (yay!), but not having disclaimer  
paperwork in to the FSF yet (boo!)...

Re: [PATCH] fix jump-misses-init warnings

[Ken Raeburn]

On Sep 14, 2009, at 03:37, Ludovic Courtès wrote:
Why does it help to move locals to the enclosing scope?  I’d expect  
the

opposite.


Jumping over the initializer is a simpler analysis than used-before- 
set.  It may also yield different results, if the "goto" that branches  
into the block and bypasses the initializer can now be reached through  
a path that retains a value of the variable in question stored by a  
previous pass through that block entering at the top.  You could still  
warn "possibly used before set", unless that's the only way to get to  
that goto statement.


If the logic of the function requires recalculating the value on any  
entry to the block, moving the declaration to an outer block is just  
masking the bug, not fixing it.


In this case, though, nothing after the label uses the value of the  
variable for which the initialization is bypassed, so it seems okay.   
Though, I'd think the declaration could be left in the same scope, and  
just split into a declaration without initializer and a separate  
assignment statement; that would probably suppress the warning without  
triggering a used-before-set warning, and wouldn't require renaming  
all the other "n" variables.  (If it doesn't, I think it might be a  
smaller change to rename the variable for which the declaration is  
being moved, rather than all the others.)


Ken

Re: can't configure --with-libgmp-prefix; header search order

[Ken Raeburn]

On Aug 4, 2009, at 15:17, Andy Wingo wrote:
In config.log I see that it's not using the -L option when testing  
for

__gmpz_init:


I think I've fixed this. Can you pull from git and give it another go?


Starting with the current git code, and fixing an autogen problem (on  
Mac OS X we want to run "glibtool" because "libtool" is some other  
program), configure with --with-libgmp-prefix seems to work fine.


Compilation fails, first for unrelated reasons:

cc1: warnings being treated as errors
../../libguile/srfi-13.c: In function ‘string_titlecase_x’:
../../libguile/srfi-13.c:2517: warning: comparison is always false due  
to limited range of data type
../../libguile/srfi-13.c:2517: warning: comparison is always false due  
to limited range of data type


If I disable -Werror with "make GCC_CFLAGS=", it gets a bit further,  
and then:


Making all in guile-readline
../libguile/guile-snarf -o readline.x ../../guile-readline/readline.c - 
DHAVE_CONFIG_H  -I. -I.. -I../../guile-readline/.. -I../../guile- 
readline/lib -I./lib  -g -O2

In file included from ../../guile-readline/readline.c:29:
../../guile-readline/../libguile.h:25:17: error: gmp.h: No such file  
or directory

Re: guile dlopen problems on Mac OS X

[Ken Raeburn]

On Aug 4, 2009, at 15:22, Andy Wingo wrote:

The correct suffix for dynamically-linked libraries on Mac OS X is
".dylib".


This is just a problem in the error message; the .so string comes from
libltdl, not from Guile.


If I adjust LD_LIBRARY_PATH but don't create the .so symlink, "guile- 
tools compile ..." fails.

If I adjust LD_LIBRARY_PATH and create the .so symlink, it works.
So, I think it really is searching for the file with the .so suffix.


However, even if I make a symlink with the .so suffix, I still get  
the

same error reported.  If I also set LD_LIBRARY_PATH to point to this
directory, then it works.


Do you mean DYLD_LIBRARY_PATH, or DYLD_FALLBACK_LIBRARY_PATH ? There  
is
also LTDL_LIBRARY_PATH, which is the one that I think should work,  
but I

think in that case there is a libltdl bug on mac os that forces me to
use DYLD_FALLBACK_LIBRARY_PATH on the machines that I'm interested in.


The dlopen man page on 10.5 says it checks $LD_LIBRARY_PATH,  
$DYLD_LIBRARY_PATH, the current working directory, and  
$DYLD_FALLBACK_LIBRARY_PATH, in that order, if there's no slash in the  
name.  If there is a slash, the handling is a bit different, and  
LD_LIBRARY_PATH is not used.  I changed LD_LIBRARY_PATH in my test.



But this isn't necessary to simply invoke
the "guile" or "guile-tools" executables.  Perhaps they should ensure
that the installation library directory gets searched via one of the
environment variables dlopen checks, or check that directory   
explicitly
if dlopen fails?  They do have built-in knowledge of where  to find  
the

Scheme code they want to load; why should the supplied  executable
libraries be different?


Good question. Probably scm_dynamic_link should ensure that the right
dir is in ltdl's path. Care to submit a patch? :-)


Thinking about it. :-)  It'll get me away from the Emacs code for a  
little while


Ken

guile 1.9.1 crash trying to profile code

[Ken Raeburn]

% guile
Guile Scheme interpreter 0.5 on Guile 1.9.1
Copyright (C) 2001-2008 Free Software Foundation, Inc.

Enter `,help' for help.
scheme@(guile-user)> ,pr (cons 1 2)
Backtrace:
In ../../module/ice-9/boot-9.scm:
3364: 0* [top-repl]
In unknown file:
   ?: 1* [dynamic-wind # # #]
In ../../module/ice-9/boot-9.scm:
3387: 2* [#]
In ../../module/system/repl/repl.scm:
 105: 3  [prompt-loop]
In ../../module/system/repl/repl.scm:
  88: 4  [call-with-backtrace #]
In unknown file:
   ?: 5* [catch #t #t ...]

ERROR: In procedure catch:
ERROR: Wrong number of arguments to #
Backtrace:
In ../../module/ice-9/boot-9.scm:
3364: 0* [top-repl]
In unknown file:
   ?: 1* [dynamic-wind # # #]
In ../../module/ice-9/boot-9.scm:
3387: 2* [#]
In ../../module/system/repl/repl.scm:
 105: 3  [prompt-loop]
In ../../module/system/repl/repl.scm:
  88: 4  [call-with-backtrace #]
In unknown file:
   ?: 5* [catch #t #t ...]

ERROR: In procedure catch:
ERROR: Wrong number of arguments to #
%

guile dlopen problems on Mac OS X

[Ken Raeburn]

After installing 1.9.1 on Mac OS X (10.5.7), and updating $PATH to  
point to the installation 'bin' directory:


% guile-tools compile -o ack.go ack.scm
ERROR: In procedure dynamic-link:
ERROR: file: "libguile-srfi-srfi-1-v-4", message: "dlopen(libguile- 
srfi-srfi-1-v-4.so, 9): image not found"

%

The correct suffix for dynamically-linked libraries on Mac OS X is  
".dylib".


% find dev/guile/guile-1.9.1/b/I -name \*srfi-1-v-4\* -print
dev/guile/guile-1.9.1/b/I/lib/libguile-srfi-srfi-1-v-4.4.dylib
dev/guile/guile-1.9.1/b/I/lib/libguile-srfi-srfi-1-v-4.a
dev/guile/guile-1.9.1/b/I/lib/libguile-srfi-srfi-1-v-4.dylib
dev/guile/guile-1.9.1/b/I/lib/libguile-srfi-srfi-1-v-4.la
%

However, even if I make a symlink with the .so suffix, I still get the  
same error reported.  If I also set LD_LIBRARY_PATH to point to this  
directory, then it works.  But this isn't necessary to simply invoke  
the "guile" or "guile-tools" executables.  Perhaps they should ensure  
that the installation library directory gets searched via one of the  
environment variables dlopen checks, or check that directory  
explicitly if dlopen fails?  They do have built-in knowledge of where  
to find the Scheme code they want to load; why should the supplied  
executable libraries be different?


Ken

can't configure --with-libgmp-prefix; header search order

[Ken Raeburn]

First, a minor nit:

% ./configure --help |& head -1
`configure' configures guile 1.9.0 to adapt to many kinds of systems.
% ./configure --version | head -1
guile configure 1.9.0
%

But I downloaded 1.9.1, not 1.9.0; the version number reported here is  
wrong.


% ../configure --prefix=`pwd`/I --with-libgmp-prefix=/opt/local --with- 
libunistring-prefix=`cd ../../libunistring-0.9.1/I/&&pwd`

[...]
checking whether csqrt is usable... yes
checking how to link with libgmp... -L/opt/local/lib -lgmp
checking for __gmpz_init in -lgmp... no
configure: error: GNU MP not found, see README
%

In config.log I see that it's not using the -L option when testing for  
__gmpz_init:


configure:44666: checking how to link with libgmp
configure:45113: result: -L/opt/local/lib -lgmp
configure:45150: checking for __gmpz_init in -lgmp
configure:45185: gcc -o conftest -g -O2 -I/Users/raeburn/dev/guile/ 
libunistring-0.9.1/I/include -I/opt/local/include  conftest.c -lgmp  - 
lm -lltdl  >&5

ld: library not found for -lgmp
collect2: ld returned 1 exit status
configure:45192: $? = 1

(This is on Mac OS X 10.5.)

If instead I use CPPFLAGS and LDFLAGS on the configure command line to  
specify the /opt/local directories, configure happily runs to  
completion.  However, the build fails:


Undefined symbols:
  "_scm_cells_allocated", referenced from:
  _scm_cells_allocated$non_lazy_ptr in libtest_asmobs_la-test- 
asmobs-lib.o

ld: symbol(s) not found
collect2: ld returned 1 exit status

This is because the build process for the test suite is picking up the  
installed Guile 1.8.7 headers (in the same MacPorts directory where  
I'm getting GNU MP from) before the guile-1.9.1 ones, as I reported  
back in June.


Ken

Re: Conflict with HDF5 libraries

[Ken Raeburn]

On Feb 4, 2009, at 12:21, Mark Patterson wrote:

Hello,

I've run into a conflict between guile (1.8.5) and HDF5 (1.8.1) on  
Fedora 10. I'll post on both mailing lists as I'm not sure who is in  
the best position to fix it.


If they're not using package-specific prefixes on symbol names, I'd  
suggest both of them should be fixed...


Ken

Re: MinGW port

[Ken Raeburn]

On Sep 9, 2006, at 14:14, Nils Durner wrote:

Hi,

first of all, sorry for the late reply.


- execv (exec_file, exec_argv);
+ execv (exec_file,
+#ifdef __MINGW32__
+ (const char * const *)
+#endif
+ exec_argv);


Is the execv declaration (in some header file) part of mingw, or  
Windows?


The SUSv2 spec (http://opengroup.org/onlinepubs/007908799/xsh/ 
exec.html) and the POSIX.1 2004 spec (http://www.opengroup.org/ 
onlinepubs/95399/functions/exec.html) say "char *const argv[]",  
i.e., no "const" qualifier on the character data.  So does the Mac OS  
X man page I just pulled up, and the Linux (GNU libc) one.  Sounds  
like Windows/Mingw is the odd one out -- and, one could argue, wrong.




Thanks for the patch, but do you understand exactly what the
Win32/MinGW compiler is complaining about?

No, I don't.
IMHO, gcc treats "const char *const *" wrong.


It treats it consistently with the ANSI C standard.  A "char **"  
value can't be assigned to a "const char * const *" lvalue without  
explicit conversion.  You can add qualifiers at the first level of  
indirection only.


There's a weird broken case you can construct if you allow that, but  
I forget the details.  I think it was something like:


void function1 () {
  char **stringarray = calloc(10, sizeof(char*));
  function2 (stringarray); // invalid
  stringarray[0][0] = 0;
}
void function2 (const char **ptr) {
  static const char x[] = { /*...*/ };
  ptr[0] = x;
}

Now, if you allow the call to function2 without casting, this code  
would have no type errors but the assignment at the end of function1  
would be writing into storage defined as const.  (String literals  
introduce some similar unfortunate lossage, when they're treated as  
"char*" values, but that's a known issue, and not what's happening  
here.)


The C++ rules are more complicated, and allow adding qualifiers at  
different levels of indirection, but with other restrictions that  
still prevent this sort of thing from happening.



I thought it was generally
OK to pass a non-const value to a function whose corresponding
parameter is declared as const.

Right.


First level of indirection only.  Same for "volatile".



The sample code for execv() at

http://msdn.microsoft.com/library/en-us/vccore98/HTML/_crt__execv. 
2c_._wexecv.asp

triggers the same warning with GCC.
I have no access to a Visual C compiler ATM, but I doubt MS' sample  
code

causes warnings with their compiler.


That's for a function "_execv".  Is "execv" also defined by MS- 
provided headers?  By mingw?  By Guile?  If execv is defined as a  
macro expanding to _execv, perhaps it should be casting its  
argument's type.


Ken


___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

current CVS guile-core doesn't build with srcdir != "."

[Ken Raeburn]

Building the srfi subtree doesn't work because the .la files are
created in the build tree, not the source tree.

Ken


Index: srfi/Makefile.am
===
RCS file: /cvs/guile/guile-core/srfi/Makefile.am,v
retrieving revision 1.13
diff -p -u -r1.13 Makefile.am
--- srfi/Makefile.am2001/11/02 00:19:42 1.13
+++ srfi/Makefile.am2001/11/03 19:16:58
@@ -35,11 +35,11 @@ BUILT_SOURCES = srfi-13.x srfi-14.x srfi
 libguile_srfi_srfi_13_14_la_SOURCES = srfi-13.x srfi-13.c srfi-14.x srfi-14.c\
  srfi-13.h srfi-14.h
 libguile_srfi_srfi_13_14_la_LDFLAGS = -version-info 0:0 -export-dynamic -no-undefined
-libguile_srfi_srfi_13_14_la_LIBADD = $(top_srcdir)/libguile/libguile.la
+libguile_srfi_srfi_13_14_la_LIBADD = ../libguile/libguile.la
 
 libguile_srfi_srfi_4_la_SOURCES = srfi-4.x srfi-4.c srfi-4.h
 libguile_srfi_srfi_4_la_LDFLAGS = -version-info 0:0 -export-dynamic -no-undefined
-libguile_srfi_srfi_4_la_LIBADD = $(top_srcdir)/libguile/libguile.la
+libguile_srfi_srfi_4_la_LIBADD = ../libguile/libguile.la
 
 srfidir = $(datadir)/guile/$(VERSION)/srfi
 srfi_DATA = srfi-1.scm \

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile