Mac Intel Leopard guile 1.8.4 link fails

Mac Intel Leopard guile 1.8.4 link fails

[Roger Mc Murtrie]

Mac OSX 10.5.2

./configure
make

Link failed at
gcc -dynamiclib  -o .libs/libguile.17.1.2.dylib .....

ld: warning codegen in ___gmpn_popcount (offset 0x00000007) prevents  
image from loading in dyld shared cache
ld: warning codegen in ___gmpn_popcount (offset 0x0000000E) prevents  
image from loading in dyld shared cache
ld: warning codegen in ___gmpn_popcount (offset 0x00000015) prevents  
image from loading in dyld shared cache
ld: warning codegen in ___gmpn_hamdist (offset 0x00000007) prevents  
image from loading in dyld shared cache
ld: warning codegen in ___gmpn_hamdist (offset 0x0000000E) prevents  
image from loading in dyld shared cache
ld: warning codegen in ___gmpn_hamdist (offset 0x00000015) prevents  
image from loading in dyld shared cache
ld: absolute addressing (perhaps -mdynamic-no-pic) used in  
___gmpn_add_n from /usr/local/lib/libgmp.a(add_n.o) not allowed in  
slidable image
collect2: ld returned 1 exit status
make[3]: *** [libguile.la] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Re: Mac Intel Leopard guile 1.8.4 link fails

[Neil Jerram]

Roger Mc Murtrie <rogermc@iinet.net.au> writes:

> Mac OSX 10.5.2
>
> ./configure
> make
>
> Link failed at
> gcc -dynamiclib  -o .libs/libguile.17.1.2.dylib .....
>
> ld: warning codegen in ___gmpn_popcount (offset 0x00000007) prevents
> image from loading in dyld shared cache
> ld: warning codegen in ___gmpn_popcount (offset 0x0000000E) prevents
> image from loading in dyld shared cache
> ld: warning codegen in ___gmpn_popcount (offset 0x00000015) prevents
> image from loading in dyld shared cache
> ld: warning codegen in ___gmpn_hamdist (offset 0x00000007) prevents
> image from loading in dyld shared cache
> ld: warning codegen in ___gmpn_hamdist (offset 0x0000000E) prevents
> image from loading in dyld shared cache
> ld: warning codegen in ___gmpn_hamdist (offset 0x00000015) prevents
> image from loading in dyld shared cache
> ld: absolute addressing (perhaps -mdynamic-no-pic) used in
> ___gmpn_add_n from /usr/local/lib/libgmp.a(add_n.o) not allowed in
> slidable image
> collect2: ld returned 1 exit status
> make[3]: *** [libguile.la] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2

Hi Roger,

Thanks for reporting this.  I was just wondering if this is a
regression since 1.8.3 - i.e. a problem that we've introduced by
something between 1.8.3 and 1.8.4.

As far as I remember, the 1.8.3 Leopard build was blocked by "64" API
problems, but I think you managed to work around those.  If you can
still remember, did the build then complete?

If it did complete, I guess this must be a regression.

Regards,
    Neil

Re: Mac Intel Leopard guile 1.8.4 link fails

[Roger Mc Murtrie]

On 24/02/2008, at 8:53 PM, Neil Jerram wrote:

> Roger Mc Murtrie <rogermc@iinet.net.au> writes:
>
>> Mac OSX 10.5.2
>>
>> ./configure
>> make
>>
>> Link failed at
>> gcc -dynamiclib  -o .libs/libguile.17.1.2.dylib .....
>>
>> ld: warning codegen in ___gmpn_popcount (offset 0x00000007) prevents
>> image from loading in dyld shared cache
>> ld: warning codegen in ___gmpn_popcount (offset 0x0000000E) prevents
>> image from loading in dyld shared cache
>> ld: warning codegen in ___gmpn_popcount (offset 0x00000015) prevents
>> image from loading in dyld shared cache
>> ld: warning codegen in ___gmpn_hamdist (offset 0x00000007) prevents
>> image from loading in dyld shared cache
>> ld: warning codegen in ___gmpn_hamdist (offset 0x0000000E) prevents
>> image from loading in dyld shared cache
>> ld: warning codegen in ___gmpn_hamdist (offset 0x00000015) prevents
>> image from loading in dyld shared cache
>> ld: absolute addressing (perhaps -mdynamic-no-pic) used in
>> ___gmpn_add_n from /usr/local/lib/libgmp.a(add_n.o) not allowed in
>> slidable image
>> collect2: ld returned 1 exit status
>> make[3]: *** [libguile.la] Error 1
>> make[2]: *** [all] Error 2
>> make[1]: *** [all-recursive] Error 1
>> make: *** [all] Error 2
>
> Hi Roger,
>
> Thanks for reporting this.  I was just wondering if this is a
> regression since 1.8.3 - i.e. a problem that we've introduced by
> something between 1.8.3 and 1.8.4.
>
> As far as I remember, the 1.8.3 Leopard build was blocked by "64" API
> problems, but I think you managed to work around those.  If you can
> still remember, did the build then complete?
>
> If it did complete, I guess this must be a regression.
>
> Regards,
>    Neil

Hi Neil,
	We ended up building 1.8.3 successfully with Leopard using ./ 
configure without any switches etc.
The 64 problem was avoided,  I think, by not defining HAVE_STAT64  in  
the config.h.in file:
/* Define to 1 if you have the `stat64' function. */
/* #undef HAVE_STAT64 */
The generated 1.8.3 then contained
/* Define to 1 if you have the `stat64' function. */
/* #undef HAVE_STAT64 */

The supplied 1.8.4 config.h.in file has
/* Define to 1 if you have the `stat64' function. */
#undef HAVE_STAT64

and
/* Define to 1 in order to try to use "64" versions of system and  
library
    calls. */
#undef GUILE_USE_64_CALLS
which I seem to recall had to do with a proposed solution for Mac OSX?

But the 1.8.4 config.h has
/* Define to 1 if you have the `stat64' function. */
#define HAVE_STAT64 1

I tried running autoconf but configure still generated a config.h with
#define HAVE_STAT64 1

I'll try changing config.h to
#undef HAVE_STAT64
I'll let ypu know the result.

Fortunately, I still have the 1.8.3 build files.

Regards
Roger

Re: Mac Intel Leopard guile 1.8.4 link fails

[Roger Mc Murtrie]

Hi Neil.

I wonder if its got something to do with my GMP version:
/usr/local/lib/libgmp.3.4.2.dylib

Regards
Roger

On 26/02/2008, at 8:39 AM, Neil Jerram wrote:

> Torbjorn Granlund <tg@swox.com> writes:
>
>> If you file a proper bug report, with all the facts and with a test
>> case, then we can perhaps help.
>>
>> http://gmplib.org/manual/Reporting-Bugs.html
>
> That's fair enough.  I guess I was hoping that this was something
> you've seen before, and so could throw some light on without a "proper
> bug report".
>
> Given that it isn't, we'll work on the proper reporting!
>
> Regards,
>      Neil
>
>

Re: Mac Intel Leopard guile 1.8.4 link fails

[Neil Jerram]

Roger Mc Murtrie <rogermc@iinet.net.au> writes:

> Hi Neil.
>
> I wonder if its got something to do with my GMP version:
> /usr/local/lib/libgmp.3.4.2.dylib
>
> Regards
> Roger

Maybe.  What release version of GMP does that correspond to?  (Note
that shared library numbers are not necessarily the same as release
numbers.)

     Neil

Re: Mac Intel Leopard guile 1.8.4 link fails

[Hans Aberg]

On 23 Feb 2008, at 20:57, Neil Jerram wrote:

> Guile uses GMP as you may know, and one of our MacOS users has
> reported the following link error, which appears to be related to GMP.

Have you tried Guile 1.8.1 in MacPorts? - It seems to work on PPC G4.

   Hans Aberg

Re: Mac Intel Leopard guile 1.8.4 link fails

[Roger Mc Murtrie]

Well, Maybe not!
For gmp-4.2.2 I just did
./configure
make
sudo make install

then for guile-1.8.4
./configure
make
Success!
make check
All tests passed.

Mysterious!
Regards

Roger


On 28/02/2008, at 9:11 AM, Roger Mc Murtrie wrote:

> The release version appears to be gmp-4.2.2
>
> Roger
>
> On 26/02/2008, at 7:31 PM, Neil Jerram wrote:
>
>> Roger Mc Murtrie <rogermc@iinet.net.au> writes:
>>
>>> Hi Neil.
>>>
>>> I wonder if its got something to do with my GMP version:
>>> /usr/local/lib/libgmp.3.4.2.dylib
>>>
>>> Regards
>>> Roger
>>
>> Maybe.  What release version of GMP does that correspond to?  (Note
>> that shared library numbers are not necessarily the same as release
>> numbers.)
>>
>>    Neil
>

Re: Mac Intel Leopard guile 1.8.4 link fails

[Neil Jerram]

Roger Mc Murtrie <rogermc@iinet.net.au> writes:

> Well, Maybe not!
> For gmp-4.2.2 I just did
> ./configure
> make
> sudo make install
>
> then for guile-1.8.4
> ./configure
> make
> Success!
> make check
> All tests passed.
>
> Mysterious!
> Regards

Well that's good news.  I'm sure there are subtle build
inconsistencies that might account for the problem that you were
getting before, so I won't worry about that further until and unless
it happens consistently again.

Many thanks for all your help with reporting and testing!

Regards,
     Neil