Re: bug#48088: libtool hardcodes native (cross-)compiler, incorrect when using libtool as cross-compiler

Hi Maxime, Maxime Devos skribis: > $ cat $(guix build libtool)/bin/libtool > Some relevant output: [...] > However, during linking, (at least during the compilation of libtomsmath > IIRC), > libtool uses LTCC instead. Thus, when a package X has libtool in > native-inputs, The ‘libtool’ scr

Re: Building shared libraries at configuration time

Hi Bob, Bob Friesenhahn writes: > On Tue, 1 Jun 2010, Ludovic Courtès wrote: >>> On Tue, 1 Jun 2010, Ludovic Courtès wrote: >>> >>>> Hello, >>>> >>>> GNU Guile relies on TLS (thread-local storage) support where available, >>>

Re: Building shared libraries at configuration time

Hi Ralf, Ralf Wildenhues writes: > * Ludovic Courtès wrote on Tue, Jun 01, 2010 at 01:15:32AM CEST: >> So it seems that the right test, when compiling natively, involves >> building a shared library and an executable linked against it, and >> running that executable. Tha

Re: Building shared libraries at configuration time

Hi Bob, Bob Friesenhahn writes: > On Tue, 1 Jun 2010, Ludovic Courtès wrote: > >> Hello, >> >> GNU Guile relies on TLS (thread-local storage) support where available, >> and can live without it on inferior systems. However, I haven’t found a >> reliable w

Building shared libraries at configuration time

Hello, GNU Guile relies on TLS (thread-local storage) support where available, and can live without it on inferior systems. However, I haven’t found a reliable way to check whether TLS is supported. Initially, TLS support was tested with: AC_LINK_IFELSE([AC_LANG_PROGRAM([__thread int tls_inte

Re: Building a Libtool 2 package with libltdl from 1.5

Hello, [EMAIL PROTECTED] (Ludovic Courtès) writes: > The question now is: will people be able to build tarballs that come > with Libtool 2.2 with from Libtool 1.5? The answer is actually "no", precisely because of this additional line in (missing from 1.5) [*]: #define lt_p

Re: Building a Libtool 2 package with libltdl from 1.5

Hello, Ralf Wildenhues <[EMAIL PROTECTED]> writes: > * Ludovic Courtès wrote on Tue, Nov 25, 2008 at 09:38:53AM CET: >> The Guile project is considering moving from Libtool 1.5 to 2.2. We >> noticed subtle incompatibilities when people tried to compile Guile >> tarb

Re: Building a Libtool 2 package with libltdl from 1.5

Hi, Bob Friesenhahn <[EMAIL PROTECTED]> writes: > On Tue, 25 Nov 2008, Ludovic Courtès wrote: >> >> The question now is: will people be able to build tarballs that come >> with Libtool 2.2 with from Libtool 1.5? > > I don't think there was ever any inte

Building a Libtool 2 package with libltdl from 1.5

Hello, The Guile project is considering moving from Libtool 1.5 to 2.2. We noticed subtle incompatibilities when people tried to compile Guile tarballs (which use Libtool 1.5 up to now) with from Libtool 2.2 [0]. The question now is: will people be able to build tarballs that come with Libtool

Re: A versionized variation on `lt_dlopen ()'

Hello Ralf, Ralf Wildenhues <[EMAIL PROTECTED]> writes: > Do I understand correctly that the problem discussed there does not > really revolve around different interfaces of the module you try to > load, but first of all of the module loader? Right. The main problem is: a module's dynamic libra

Re: A versionized variation on `lt_dlopen ()'

Hi Ralf, Ralf Wildenhues <[EMAIL PROTECTED]> writes: > Can you give a pointer to the thread? I couldn't find it easily (i.e., > within one minute :) Probably because it's inappropriately entitled. ;-) It starts here: http://lists.gnu.org/archive/html/guile-user/2005-09/msg00061.html . And I

A versionized variation on `lt_dlopen ()'

Hi, After reading a recent thread on `guile-user', it occurred to me that `lt_dlopenext ()' doesn't allow to pass information about the version of a module that is requested. This is quite unfortunate, especially for Guile, since Guile modules load C libraries using `dynamic-link' which is roughl