Re: How does one specify linking to 64 bit libraries when there is a choice?

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Bruce Korb]

Hi Nelson,

I am nearly certain we (you) have reached a point where
libtool folks are going to say, "it is Guile", and Guile
folks are going to say, "it is libtool".  I am going to
say, "I'd like some help from either or both".

Because the guile-config invokes the guile binary in order
to print out the unvarying strings from the configuration,
it requires reverse engineering the entire Guile package
to fully understand how it comes up with the strings it
does.  I can do it, but I am not any more eager than you.

I think first up, someone from Guile needs to analyze
the machinery behind "guile-config".  I am willing to
help with test runs on the utah.edu machines in order
to diagnose the issue.

Cheers - Bruce

On 12/17/10 11:57, Nelson H. F. Beebe wrote:
> Well, I have now done three more builds of guile-1.8.8.  The first and
> second supplied libdir=/usr/local/lib64 on the command line of all
> "make" runs.  That did not help: /usr/local/bin/guile-config still
> reported -L/usr/local/lib.
> 
> I found that LTLIBICONV still has -L/usr/local/lib in the first
> attempt, so I replaced it by LTLIBICONV=-liconv for the second
> attempt.
> 
> For the third, I did "make clean", then used sed -i + xargs to
> explicitly set libdir in every Makefile, in case it is not being
> passed correctly to child makes.
> 
> That too does not help:
> 
> % /usr/local/bin/guile-config link | fmt -w 10
>  -pthread
>  -L/usr/local/lib
>  -lguile
>  -lltdl
>  -L/usr/local/lib64
>  -Wl,-rpath,/usr/local/lib64
>  -lgmp
>  -lcrypt
>  -lm
>  -lltdl
> 
> For the fourth try, I used sed + xargs again to force all references
> to the iconv library to just use a bare -liconv.  Sadly, the incorrect
> -L/usr/local/lib option still appears.
> 
> % guile
> guile> (define (get-build-info name)
>   (let ((val (assq name %guile-build-info)))
>     (if (not (pair? val))
>         (begin
>           (display-line-error
>            program-name " " subcommand-name ": no such build-info: " name)
>           (quit 2)))
>     (cdr val)))
> guile> (get-build-info 'LIBS)
> "-L/usr/local/lib64 -Wl,-rpath,/usr/local/lib64  -lgmp -lcrypt -lm -lltdl "
> guile> (get-build-info 'libdir)
> "/usr/local/lib"
> 
> I'm unsure of where to proceed at this point.  The logs of the four
> tries are in
> 
>     /usr/local/gnu/src/guile/logs/guile-1.8.8/Typescript.abajo.math.utah.edu.2010.12.17.12.12.44.xz
> 
> P.S. I leave the country on a 3-week trip next Saturday (25-Dec-2010),
> and I won't have computer access during that time.

That will be after I leave (22-Dec), but I get back 12/27
(400 miles is still within the US).  I would hope this is
resolved before next Wednesday.......Have a nice trip & holiday!
Regards, Bruce

_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Noah Lavine]

Hello,

I am not at all an expert on guile-config, but I will help if I can.

First of all, as to how guile-config works. At least in the latest git
version, it seems to be a thin wrapper for pkg-config.

I found the file that pkg-config will be using to give you this
information. It is meta/guile-<version number>.pc in my Guile source
tree. Furthermore, I think it's safe to assume that it is generated
from meta/guile-<version number>.pc.in.

But that file is just a pretty innocuous-looking template where it
looks like you paste some variables that would be generated by the
configure script.

Therefore, I have this question for you - are you able to configure
Guile to use 64-bit libs using the configure script?

Noah Lavine

On Fri, Dec 17, 2010 at 3:10 PM, Bruce Korb <bruce.korb@gmail.com> wrote:
> Hi Nelson,
>
> I am nearly certain we (you) have reached a point where
> libtool folks are going to say, "it is Guile", and Guile
> folks are going to say, "it is libtool".  I am going to
> say, "I'd like some help from either or both".
>
> Because the guile-config invokes the guile binary in order
> to print out the unvarying strings from the configuration,
> it requires reverse engineering the entire Guile package
> to fully understand how it comes up with the strings it
> does.  I can do it, but I am not any more eager than you.
>
> I think first up, someone from Guile needs to analyze
> the machinery behind "guile-config".  I am willing to
> help with test runs on the utah.edu machines in order
> to diagnose the issue.
>
> Cheers - Bruce
>
> On 12/17/10 11:57, Nelson H. F. Beebe wrote:
>> Well, I have now done three more builds of guile-1.8.8.  The first and
>> second supplied libdir=/usr/local/lib64 on the command line of all
>> "make" runs.  That did not help: /usr/local/bin/guile-config still
>> reported -L/usr/local/lib.
>>
>> I found that LTLIBICONV still has -L/usr/local/lib in the first
>> attempt, so I replaced it by LTLIBICONV=-liconv for the second
>> attempt.
>>
>> For the third, I did "make clean", then used sed -i + xargs to
>> explicitly set libdir in every Makefile, in case it is not being
>> passed correctly to child makes.
>>
>> That too does not help:
>>
>> % /usr/local/bin/guile-config link | fmt -w 10
>>  -pthread
>>  -L/usr/local/lib
>>  -lguile
>>  -lltdl
>>  -L/usr/local/lib64
>>  -Wl,-rpath,/usr/local/lib64
>>  -lgmp
>>  -lcrypt
>>  -lm
>>  -lltdl
>>
>> For the fourth try, I used sed + xargs again to force all references
>> to the iconv library to just use a bare -liconv.  Sadly, the incorrect
>> -L/usr/local/lib option still appears.
>>
>> % guile
>> guile> (define (get-build-info name)
>>   (let ((val (assq name %guile-build-info)))
>>     (if (not (pair? val))
>>         (begin
>>           (display-line-error
>>            program-name " " subcommand-name ": no such build-info: " name)
>>           (quit 2)))
>>     (cdr val)))
>> guile> (get-build-info 'LIBS)
>> "-L/usr/local/lib64 -Wl,-rpath,/usr/local/lib64  -lgmp -lcrypt -lm -lltdl "
>> guile> (get-build-info 'libdir)
>> "/usr/local/lib"
>>
>> I'm unsure of where to proceed at this point.  The logs of the four
>> tries are in
>>
>>     /usr/local/gnu/src/guile/logs/guile-1.8.8/Typescript.abajo.math.utah.edu.2010.12.17.12.12.44.xz
>>
>> P.S. I leave the country on a 3-week trip next Saturday (25-Dec-2010),
>> and I won't have computer access during that time.
>
> That will be after I leave (22-Dec), but I get back 12/27
> (400 miles is still within the US).  I would hope this is
> resolved before next Wednesday.......Have a nice trip & holiday!
> Regards, Bruce
>
>

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Andy Wingo]

Hello,

When a work subscription to libtool and a home subscription to
guile-devel collide...

On Mon 20 Dec 2010 05:40, Noah Lavine <noah.b.lavine@gmail.com> writes:

> I found the file that pkg-config will be using to give you this
> information. It is meta/guile-<version number>.pc in my Guile source
> tree. Furthermore, I think it's safe to assume that it is generated
> from meta/guile-<version number>.pc.in.

I think with 1.8, which is what Nelson is trying to build, it's still a
fairly thick thing.

>> On 12/17/10 11:57, Nelson H. F. Beebe wrote:
>>> /usr/local/bin/guile-config still reported -L/usr/local/lib.

Usually if you have 64-bit libs in lib64, you have to pass --libdir
explicitly.

So you would configure guile using:

    ./configure --prefix=/usr/local --libdir=/usr/local/lib64

If you still get /usr/local/lib coming out in guile's configure, you may
have a libtool-related issue, but I doubt it.

Cheers,

ANdy

_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Bruce Korb]

On 12/19/10 20:40, Noah Lavine wrote:
> Hello,
> 
> I am not at all an expert on guile-config, but I will help if I can.

Thank you to all who responded.

> Usually if you have 64-bit libs in lib64, you have to pass --libdir
> explicitly.

We've now concluded that that is, indeed, the answer to the
original question.  The fallout question:

  How much understanding of the machinery should be expected
  of the hapless project builder?

Nelson has been doing this stuff for quite a while and has
reasonably good understanding of the process.  From that
understanding, he made the assumption that a standard 64 bit
"Red Hat Enterprise Linux Server release 5.5 (Tikanga)"
installation would be compatible with installing Guile via
   ./configure && make && sudo make install
and not wind up with a frumitzed `guile-config link` output.
The assumption was incorrect and we now know that.

Perhaps we can strive to make the assumption correct
in the future?

Thank you!  Regards, Bruce

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Andy Wingo]

Hi Bruce,

Sorry you and others have had to suffer through this.

On Mon 20 Dec 2010 15:09, Bruce Korb <bkorb@gnu.org> writes:

>   How much understanding of the machinery should be expected
>   of the hapless project builder?

I'm not sure, but:

> Nelson has been doing this stuff for quite a while and has
> reasonably good understanding of the process.  From that
> understanding, he made the assumption that a standard 64 bit
> "Red Hat Enterprise Linux Server release 5.5 (Tikanga)"
> installation would be compatible with installing Guile via
>    ./configure && make && sudo make install

This is incorrect, for RHEL and other systems which place 64-bit libs in
$prefix/lib64.  You will find hacks to set --libdir in almost all
packaging scripts.

> Perhaps we can strive to make the assumption correct
> in the future?

This idea is attractive, if it can be done. But this is more an autoconf
issue (setting $libdir) than a libtool issue, and it's not a Guile issue
at all :)

Cheers,

Andy

_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Ralf Corsepius]

On 12/20/2010 03:09 PM, Bruce Korb wrote:
> On 12/19/10 20:40, Noah Lavine wrote:
>> Hello,
>>
>> I am not at all an expert on guile-config, but I will help if I can.
>
> Thank you to all who responded.
>
>> Usually if you have 64-bit libs in lib64, you have to pass --libdir
>> explicitly.
>
> We've now concluded that that is, indeed, the answer to the
> original question.  The fallout question:
>
>    How much understanding of the machinery should be expected
>    of the hapless project builder?
>
> Nelson has been doing this stuff for quite a while and has
> reasonably good understanding of the process.  From that
> understanding, he made the assumption that a standard 64 bit
> "Red Hat Enterprise Linux Server release 5.5 (Tikanga)"
> installation would be compatible with installing Guile via
>     ./configure&&  make&&  sudo make install
> and not wind up with a frumitzed `guile-config link` output.
> The assumption was incorrect and we now know that.
Correct, this assumption is incorrect.

(With my Fedora Packaging Committee member hat on) In Fedora and RHEL, 
users are supposed to pass
--libdir=/usr/lib64 to configure
on x86_64 and
--libdir=/usr/lib to configure
on i386.

Analogous conventions apply to other multilib'ed architectures.

Ralf

_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Ralf Wildenhues]

* Bruce Korb wrote on Mon, Dec 20, 2010 at 03:09:48PM CET:
>   How much understanding of the machinery should be expected
>   of the hapless project builder?

I've skimmed most of the conversation in this thread now.

The crucial part, I think, is *not* the --libdir setting.  Distros
usually get that consistent between their packages, and users should not
be using any of /usr/lib{,32,64} but rather something below /usr/local.

One crucial part is that libtool gets confused whenever it has
directories with the wrong ABI in the search path (unlike ld or ld.so,
both are in some cases smart enough to skip wrong ABI), which means that
either no instance of the build system machineries may introduce such
paths, or libtool needs to get smarter to ignore wrong ABI dirs.

The other crucial part is that libtool doesn't get the
sys_lib_search_path_spec and sys_lib_dlsearch_path_spec settings
right on several distros, introducing such wrong directories itself (not
to speak of cross setups).  There have been several proposed patches to
address this, e.g.
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10625
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9931
but I have yet to see one that solves it.

Thanks,
Ralf

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Mon, Dec 20, 2010 at 08:20:25PM CET:
> The other crucial part is that libtool doesn't get the
> sys_lib_search_path_spec and sys_lib_dlsearch_path_spec settings
> right on several distros, introducing such wrong directories itself (not
> to speak of cross setups).  There have been several proposed patches to
> address this, e.g.
> http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10625
> http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9931
> but I have yet to see one that solves it.

ESENDTOOSOON, sorry.

At least with current Libtool you can override wrong settings with the
lt_cv_sys_lib_search_path_spec and lt_cv_sys_lib_dlsearch_path_spec
cache variables.

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Bruce Korb]

Hi Nelson,

On Fri, Dec 17, 2010 at 9:09 AM, Nelson H. F. Beebe <beebe@math.utah.edu> wrote:
> The recent exchanges about the /usr/local/lib vs /usr/local/lib64
> problem with libtool + autogen + guile gave me a critical clue.  I
> examined all of the /usr/local/lib64/*.la files, and found dozens that
> mention (incorrectly) /usr/local/lib.
>
> A couple of passes with "sed -i" scripts repaired them, and I was then
> able to build guile-1.8.8 successfully on GNU/Linux AMD64 with Red Hat
> 5.5, but there are still socket test failures on Red Hat 4.8 that may
> be a separate issue.

One final question, what does the output of
   `guile-config link`
say after you have fiddled the libguile.la file?
If you have it newly installed on your down machine "abajo"
then there is still a problem:

 abajo_guile $ /usr/local/bin/guile-config link
 -pthread -L/usr/local/lib -lguile -lltdl -L/usr/local/lib64 \
-Wl,-rpath,/usr/local/lib64 -lgmp -lcrypt -lm -lltdl

The one in /usr/bin seems insufficient and it is not at the
head of the PATH list

 abajo_guile $ /usr/bin/guile-config link
-pthread -lguile

The versions:

 abajo_guile $ which -a guile
/usr/local/bin/guile
/usr/bin/guile
 abajo_guile $ for f in $(which -a guile);do $f --version|head -1;done
Guile 1.8.8
Guile 1.8.0