Building without posix

Building without posix

[Dmitry Dzhus]

Is POSIX module considered optional?

Configuring guile-2.0 and git trunk with --disable-posix results in the
following error on my x86:

make  all-am
make[3]: Entering directory `/home/sphinx/projects/trunks/guile/libguile'
  [... skipped .lo lines ...]
  CC     libguile_2.0_la-weaks.lo
  CC     dynl.lo
  CC     net_db.lo
  CC     socket.lo
  CC     regex-posix.lo
  CCLD   libguile-2.0.la
  CC     guile-guile.o
  CCLD   guile
./.libs/libguile-2.0.so: undefined reference to `scm_stat'
./.libs/libguile-2.0.so: undefined reference to `scm_i_locale_mutex'
./.libs/libguile-2.0.so: undefined reference to `scm_ttyname'
./.libs/libguile-2.0.so: undefined reference to `scm_canonicalize_path'
./.libs/libguile-2.0.so: undefined reference to `scm_i_relativize_path'
collect2: ld returned 1 exit status
make[3]: *** [guile] Error 

Re: Building without posix

[Dmitry Dzhus]

Also similar error when building without dynamic modules support:

  CCLD   libguile-2.0.la
  CCLD   guile
./.libs/libguile-2.0.so: undefined reference to `scm_dynamic_link'
./.libs/libguile-2.0.so: undefined reference to `scm_dynamic_call'
./.libs/libguile-2.0.so: undefined reference to `scm_init_dynamic_linking'
./.libs/libguile-2.0.so: undefined reference to `scm_dynamic_func'
collect2: ld returned 1 exit status

Re: Building without posix

[Ludovic Courtès]

Hi Dmitry,

Dmitry Dzhus <dima@dzhus.org> writes:

> Is POSIX module considered optional?

Not really.

> Configuring guile-2.0 and git trunk with --disable-posix results in the
> following error on my x86:

I pushed a patch that should allow Guile to be built with
‘--disable-posix’.

However, there’s quite a bit of Scheme code that needs access to POSIX
functions now, notably the compiler.  So a number of file system access
procedures must be compiled for the compiler to work.

With the patch I pushed, ./check-guile doesn’t even work because
‘readdir’ & co. are lacking.  We could change this to compile them even
with ‘--disable-posix’, but the problem is that there could be even more
of them, which would defeat the whole point of ‘--disable-posix’, I guess.

Thanks,
Ludo’.

Re: Building without posix

[Andy Wingo]

Hi!

A bit late, but...

On Fri 15 Apr 2011 00:17, ludo@gnu.org (Ludovic Courtès) writes:

> Dmitry Dzhus <dima@dzhus.org> writes:
>
>> Is POSIX module considered optional?
>
> Not really.
>
>> Configuring guile-2.0 and git trunk with --disable-posix results in the
>> following error on my x86:
>
> I pushed a patch that should allow Guile to be built with
> ‘--disable-posix’.
>
> However, there’s quite a bit of Scheme code that needs access to POSIX
> functions now, notably the compiler.  So a number of file system access
> procedures must be compiled for the compiler to work.
>
> With the patch I pushed, ./check-guile doesn’t even work because
> ‘readdir’ & co. are lacking.  We could change this to compile them even
> with ‘--disable-posix’, but the problem is that there could be even more
> of them, which would defeat the whole point of ‘--disable-posix’, I guess.

I think we should focus on the GNU system, using gnulib to adapt other
systems to look like GNU.  Disabling POSIX bindings helps no one on the
GNU system -- if the question is one of library size, the solution
should be loadable modules, not compile-time options.  We are doing very
well in that way.  A stripped libguile is 1.5MB, like libc.

That said, I don't like a lot of our POSIX bindings.  It's in the
default module, and it's lots of symbols.  But it's probably best to
migrate to some more modularized world using deprecation than to
continue with the --disable-posix fantasy.

Andy
-- 
http://wingolog.org/

Re: Building without posix

[Andy Wingo]

On Sat 02 Apr 2011 17:25, Dmitry Dzhus <dima@dzhus.org> writes:

> Also similar error when building without dynamic modules support:
>
>   CCLD   libguile-2.0.la
>   CCLD   guile
> ./.libs/libguile-2.0.so: undefined reference to `scm_dynamic_link'
> ./.libs/libguile-2.0.so: undefined reference to `scm_dynamic_call'
> ./.libs/libguile-2.0.so: undefined reference to `scm_init_dynamic_linking'
> ./.libs/libguile-2.0.so: undefined reference to `scm_dynamic_func'
> collect2: ld returned 1 exit status

Fixed, thanks.

Andy
-- 
http://wingolog.org/

Re: Building without posix

[Ludovic Courtès]

Hello!

Andy Wingo <wingo@pobox.com> skribis:

> I think we should focus on the GNU system, using gnulib to adapt other
> systems to look like GNU.  Disabling POSIX bindings helps no one on the
> GNU system -- if the question is one of library size, the solution
> should be loadable modules, not compile-time options.  We are doing very
> well in that way.  A stripped libguile is 1.5MB, like libc.

I think the compile-time option can be useful when building on a “raw”
or old system, which doesn’t support all the POSIX bits we wrap, or on a
slow system.

For instance, when we port Guile to run on the bare metal, we’ll be
happy that ‘--disable-posix --disable-networking --disable-threads’
nicely delimits the contour of what we need, won’t we?

> That said, I don't like a lot of our POSIX bindings.  It's in the
> default module, and it's lots of symbols.  But it's probably best to
> migrate to some more modularized world using deprecation than to
> continue with the --disable-posix fantasy.

Yeah.  I think it’s been on the to-do list since 1.4.  :-)

Thanks,
Ludo’.

Re: Building without posix

[Andy Wingo]

Hi :)

On Thu 30 Jun 2011 16:17, ludo@gnu.org (Ludovic Courtès) writes:

> I think the compile-time option can be useful when building on a “raw”
> or old system, which doesn’t support all the POSIX bits we wrap, or on a
> slow system.

But we check for all of the bits we do wrap, no?  It seems to me that
--disable-posix is about decreasing size, not about enabling Guile to
build on more systems.  And in fact can you think of any systems in the
last 10 years for which --disable-posix would allow you to do something
interesting?

> For instance, when we port Guile to run on the bare metal, we’ll be
> happy that ‘--disable-posix --disable-networking --disable-threads’
> nicely delimits the contour of what we need, won’t we?

This is crazy :)  We can't anticipate the needs of any such port, so
it's pointless to maintain options that probably don't work.

Regards,

Andy
-- 
http://wingolog.org/