ers wrote you need a convenience library.
However, as the code you are compiling will be part of a shared
library, you need to use appropriate compiler flags. -fPIC is
defaulted on the Apple compilers but I don't know if you need -fno-
common anymore.
Bill Northcott
smime.p7
Forget that last message. The problem I have is definitely in the
compiler driver gcc/g++
Apologies
Bill
On 17/07/2007, at 4:00 PM, Bill Northcott wrote:
There is a problem building loadable modules on Darwin/MacOS X
using libtool and FSF compilers
ug in libtool. Alternatively, it
is a bug in the compiler, although I think it is documented somewhere.
The version here is 1.5.22 on MacOS X 10.4.10 Intel using the gcc
compilers distributed with R-2.4.1.
Using Apple's compilers there does not seem to be the same issue
maybe
code to the library to allow
stack execution, but it can't be done with compiler or linker options.
Thanks again
Bill
On 10/06/2007, at 7:01 PM, Ralf Wildenhues wrote:
Hello, and apologies for the delay,
* Bill Northcott wrote on Tue, May 29, 2007 at 09:16:52AM CEST:
On 29/05/2007,
I think I have reached a dead end on this. See below:
#bar.c
void bar () {
return;
}
#foo.c
int main(int argc, void * argv) {
bar();
return 0;
}
[MBP-OGN:Public/Swarm/libtest] billn% gcc -c -fnested-functions -o
bar.o bar.c
[MBP-OGN:Public/Swarm/libtest] billn% gcc -dynamiclib -fnested-
fun
On 29/05/2007, at 4:36 PM, Peter O'Gorman wrote:
Adding '-fnested-functions' to the CFLAGS stops the compiler
barfing. However as per Apple Tech note http://
developer.apple.com/technotes/tn2006/tn2161.html it is also
necessary to add -fnested-functions or an equivalent ld flag to
the comp
S does not work because
libtool strips it out before invoking gcc.
Is there a way around this or an actual fix?
Thanks
Bill Northcott
___
http://lists.gnu.org/mailman/listinfo/libtool
On 19/02/2007, at 3:07 PM, Peter O'Gorman wrote:
Is there any support for 64 bit MacOS builds using Apple's -arch
option or FSF gcc with -m64?
In particular does it understand that some versions of gcc seem to
put 64 bit libs in lib/ppc64 or whatever?
libtool-1.5.24 will get the system searc
gcc seem to
put 64 bit libs in lib/ppc64 or whatever?
Thanks for all your work on this
Bill Northcott
___
http://lists.gnu.org/mailman/listinfo/libtool
l fail to link at runtime, even thought the
libtool version implies it is compatible.
I think your 2003 suggestion to eliminate libfoo.x.x.x.dylib is
correct. Creating that just results in unnecessary duplication.
Bill Northcott
___
http://lists.gnu.org/mailman/listinfo/libtool
On 15/05/2005, at 10:06 PM, Peter O'Gorman wrote:
Possibly, the last line could equally be:
install_name libfoo.2.dylib compatibility_version 3.0.0
current_version 3.2.15
That would have the same effect on Darwin, if applied consistently.
The encoded current_version is for informational purpose
On 15/05/2005, at 1:57 PM, Peter O'Gorman wrote:
I have so far only found one GNU libtool packages which correctly
versions its libraries on MacOS X. This is R and they seem to do
it with code in Makefile.in which overrides the libtool versioning.
Looks like R builds a framework on darwin a
On 15/05/2005, at 10:06 PM, Peter O'Gorman wrote:
Possibly, the last line could equally be:
install_name libfoo.2.dylib compatibility_version 3.0.0
current_version 3.2.15
That would have the same effect on Darwin, if applied consistently.
The encoded current_version is for informational purpose
ine'? How does a single
libtool version string get translated into the two possibly different
version strings required by MacOS X?
Bill Northcott
___
http://lists.gnu.org/mailman/listinfo/libtool
should one write specific makefile routines to adjust
version numbers at install time?
Bill Northcott
___
http://lists.gnu.org/mailman/listinfo/libtool
continue to use existing libraries according to ELF
versioning rules.
Programs linked after the newer library is installed will use the
newer library.
Which is all very nice, but does it also work on non-ELF systems such
as Darwin/MacOS X?
Bill Northcott
ous differences I can see between your build and my typical
builds are
- I use GNU make. Not sure if it's required, but I'm suspicious about
`config.status' being run as a dependency. Try using GNU make for the
build process.
I have successfully done this, and I am ver
ten days ago. Did anything
come of this? Are there any plans for such an enhancement?
Bill Northcott
Swarm Development Group
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
that wants to use libtool or the
FSF compiler. I think the FSF compiler is supposed to support Altivec
real soon now.
As far as I can see, there is only one issue which prevents our project
building with an Apple compiler. This is that th
Another member of our group suggested:
> Before installing libtool 1.5, go through the libtool.m4 and change all
> the stuff
> that says:
> if $CC -v 2>&1 | grep 'Apple' >/dev/null ; then \
> to:
> if true; then
> Then rerun libtool's `bootstrap', and reisntall.
> The basic problem is that libtool
# foo.lo - a libtool object file
# Generated by ltmain.sh - GNU libtool 1.5 (1.1220.2.1 2003/04/14
22:48:00)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.
# Name of the PIC object.
pic_object='.libs/foo.o'
# Name of the non-PIC object.
non_pic_object=none
**
into a single swarm dynamic library against which
executables would be dynamically linked. Libtool; appears to specifically
rule this out.
Or can you explain how to do it?
Bill Northcott
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.
what documentation there is and I can see no clues
how to do this.
Bill Northcott
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
> Ok, I've put some thought into this over the weekend,
> and I think it should be classified as a BUG. The
> argument you put up about library compiled as PIC
> is irrelevant on PPC. Here's a snippet from the
> libtool manual:
I would like to second that p
ool code.
>Can you tell us what happens
> in Libtool that causes this? i.e. run the same command with
> "/bin/sh -x ../../libtool" and pipe the output to a file.
I will try to do this for both cases and send you the files. I will
include another point in
ibavcall.a.
This was broken in 1.4.2. Apparently fixed in the 1.4.3 release and seems
to be broken again in 10 Feb cvs snapshot I tried yesterday.
I think we give up and use jam on MacOS X until you guys think this thing
is ported.
Bill Northcott
__
ool 'as is' prevents
this! Even LD_LIBRARY_PATH variables don't seem to help.
Bill Northcott
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
27 matches
Mail list logo
