, 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.p7s
Description: S/MIME cryptographic signature
.
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 they require -b to be followed by a space.
I know I am not the only one to hit this problem.
Bill Northcott
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
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, at 4:36 PM
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
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-
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
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
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
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
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
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
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
routines to adjust
version numbers at install time?
Bill Northcott
___
http://lists.gnu.org/mailman/listinfo/libtool
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 very sure you need GNU make.
Bill Northcott
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
can see, there is only one issue which prevents our project
building with an Apple compiler. This is that the Apple compilers crash
trying to compile a main() function with the -fgnu-runtime flag.
Bill Northcott
___
Libtool mailing list
[EMAIL
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 21 | grep 'Apple' /dev/null ; then \
to:
if true; then
Then rerun libtool's `bootstrap', and reisntall.
The basic problem is that libtool uses the
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.org/mailman/listinfo
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
.
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
___
Libtool mailing
'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
23 matches
Mail list logo
