7.8 alpha 2 is avilable as
http://pike.ida.liu.se/pub/pike/alpha/7.8.8/Pike-v7.8.8.tar.gz
It's not a beta because the changelog isn't complete. Other than that I know of no release blockers.
I've got some worries still on the Mac side:
- On PPC32 I've got strange core dumps from inside the JPEG library, but only if the _Image_JPEG module loads very late. I'm investigating a theory about conflicting symbols in the flat namespace. (Grubba and Agehall mentioned that Per might have seen this earlier. Any hints would be welcome.)
- On OS X 10.5 (at least for x86_64) I cannot build GMP into a relocatable library since Apple dropped a necesary ld flag that existed in 10.4 and earlier. That in turn means I need to disable dynamic modules. I'd like to improve this by converting Pike's GMP module to static linking while having the remaining modules dynamic since Pike always loads GMP anyway for bignum support.
JPEG crashes randomly on AMD64 as well. I suspect a 64-bit conflict in libjpeg or pike. I've failed to trace it.
Well, I'm sure it'll be fixed in all branches as soon as we discover where the bug is, and since it hasn't been fixed for the last six months I think it's a really good idea not to have it as a blocker... :)
Latest update is that I've found two copies of libjpeg in my binary. One from _Image_JPEG and another from the TIFF library since TIFF apparently supports JPEG chunks. I'll have a look if other platforms simply disable JPEG chunks in TIFF or if the problem is masked by load order (maybe they will blow up only if a suitable TIFF file is encountered).
It's on PPC 32-bit that I see the problem. In fact, I can see multiple instances of JPEG entrypoints in e.g. Linux .so files as well, but maybe the dlopen implementation is sufficiently different to avoid any issues.
A quick fix that I found is to add RTLD_LOCAL in the call to dlopen() in dynamic_load.c:f_load_module() but Grubba advised against it because there's apparently some cross-dependencies among other image modules that would break.
I'm now investigating if there are any compile-time flags that can force the .so files to bind their external library references earlier instead of delaying them until runtime. No luck yet...
Ok, that rules out 64 bit problems. Good... I think?
Have you been able to create a testcase?
Why does it rule out 64-bit systems?
Testcase that works:
darjeeling:jwtmp $ ./bin/pike Pike v7.8 release 4 running Hilfe v3.5 (Incremental Pike Frontend)
string s = Stdio.read_bytes("/tmp/jwtmp/testimg.jpg"); object i = Image.JPEG.decode(s); i;
(1) Result: Image.Image( 227 x 149 /* 99.1Kb */)
Image.JPEG.encode(i);
(2) Result: "دØ\0\20JFIF\0\1\1..."
Testcase that breaks:
darjeeling:jwtmp $ ./bin/pike Pike v7.8 release 4 running Hilfe v3.5 (Incremental Pike Frontend)
Image.TIFF;
(1) Result: _Image_TIFF
string s = Stdio.read_bytes("/tmp/jwtmp/testimg.jpg"); object i = Image.JPEG.decode(s); i;
(2) Result: Image.Image( 227 x 149 /* 99.1Kb */)
Image.JPEG.encode(i);
Segmentation fault
That it's a 64-bit-only problem, I mean.
Hmm. But...
| > string s = Stdio.read_bytes("sugar.jpg"); | > object i = Image.JPEG.decode(s); | >> i; | (1) Result: Image.Image( 300 x 300 /* 263.7Kb */) | > Image.JPEG.encode(i); | *** glibc detected *** pike: munmap_chunk(): invalid pointer: 0x0000000000a9b5d0 | *** | ======= Backtrace: ========= | /lib/libc.so.6(cfree+0x1b6)[0x2ba515677d46] | /usr/lib/libjpeg.so.62[0x2ba516a52ffa] | /usr/lib/libjpeg.so.62(jpeg_abort+0x15)[0x2ba516a52505] | /usr/local/pike/7.7.133/lib/modules/_Image_JPEG.so[0x2ba51681b888] | pike(low_mega_apply+0x598)[0x434908] | ...
I've already stepped around in gdb yesterday and also verified that hiding _Image_TIFF.so fixes the problem so I'm quite confident the reason is mixups of multiply-defined symbols at runtime. The temporary RTLD_LOCAL flag workaround also supports this theory.
Not sure I'd gain much by researching the problem more now that the cause is already understood. I'm more interested in finding a solution!
I'm now attempting to reverse the Darwin-specific -flat_namespace option that (I believe) Bill added. Maybe it's a dead end that brings back other issues but we'll see...
More testing shows that if I restore two-level namespace linking for OS X the resulting Pike works fine again. This means switching from
LDSHARED="$REALCC $CFLAGS -bundle -bind_at_load -flat_namespace -undefined suppress"
to
LDSHARED="$REALCC $CFLAGS -bundle -bind_at_load -undefined dynamic_lookup"
combined with "export MACOSX_DEPLOYMENT_TARGET=10.4".
In src/configure.in r1.568 Grubba added Bill's patch for bug #2820 which forced flat namespace (i.e. the OS X 10.0 default link mode). This bug ticket says:
After considerable fiddling, it appears that it will be necessary to use the flat namespace when compiling for Darwin (ask me offline if you need specific examples and reasons).
Bill, can you recall the rationale for this change? Otherwise one solution is to switch to my alternate LDSHARED above.
Separately Grubba and Agehall have identified a GCC visibility pragma that may solve this particular issue in image_jpeg.c and image_tiff.c. I'm rebuilding again (poor slow G4 laptop :-) and will soon report the results. Still, this would only fix the identified problem and not future issues caused by multiple symbols in other places.
I assume you're referring to the problem of multiple libjpegs being used and not problems with gmp/nettle compilation...
It's been a while since I did that; I recall that multi-level namespaces were added somewhere after 10.1 and that a lot of things were broken by it (not just pike, but libraries as well). It's possible that it's not required any more, however I can't say for sure. I think that one of the problems is that if you don't use flat_namespace, you have to have anything that links to it be available for the linker to scan. Versions since 10.3 have complicated matters more, by adding/changing behavior. Since pike modules tend to be built before pike, this was the source of multiple problems. It's worth noting that adding the MACOSX_DEPLOYMENT_TARGET effectively specifies the earliest version of OSX that can be used.
The OSX linker is a much different beast than those on other *nix platforms... the ld man page has lots of interesting and frustrating information about the divergent path apple/next took. I think 10.5 changes things yet again. Makes me really appreciate the relative stability of solaris over the years.
Bill
On Aug 14, 2008, at 12:20 PM, Jonas Walldén @ Pike developers forum wrote:
More testing shows that if I restore two-level namespace linking for OS X the resulting Pike works fine again. This means switching from
LDSHARED="$REALCC $CFLAGS -bundle -bind_at_load -flat_namespace - undefined suppress"
to
LDSHARED="$REALCC $CFLAGS -bundle -bind_at_load -undefined dynamic_lookup"
combined with "export MACOSX_DEPLOYMENT_TARGET=10.4".
In src/configure.in r1.568 Grubba added Bill's patch for bug #2820 which forced flat namespace (i.e. the OS X 10.0 default link mode). This bug ticket says:
After considerable fiddling, it appears that it will be necessary to use the flat namespace when compiling for Darwin (ask me offline if you need specific examples and reasons).
/.../ Since pike modules tend to be built before pike, this was the source of multiple problems. /.../
This has been fixed in 7.8 with the work to switch to dll's on windows. The sequencing is only enabled when required though - you'll have to add some stuff to src/configure.in so that @LDSHARED_BASE_REQS@ is replaced with a dependency on the right object.
Thanks for the comments. It's indeed the multiple libjpeg issue I'm taking a stab at here. Your fix predates 10.3 while my suggested tweak requires a 10.3+ ld feature (-undefined dynamic_lookup) so perhaps what seemed a necessity back then is better handled in this fashion nowadays. And who knows when the 10.0 compatibility mode disappears?
I can try this fix on a few more Macs before passing final judgement. I've got ppc32 on 10.4, x86 on 10.4 and x86_64 on 10.5 in Roxen's build farm.
Unfortunately I couldn't get the #pragma idea to work so it's not an option.
Yes,
I agree that a more modern solution would be preferable, if one exists (it appears that's the case with 10.3+). I would have definitely would have preferred your proposal had it been available back then.
I just confirmed that the gmp bundle compiles but results in a failure during pike linking:
Linking Gmp ld: absolute addressing (perhaps -mdynamic-no-pic) used in ___gmpn_add_nc from /Users/hww3/Downloads/Pikev7.8.8/build/ darwin-9.2.1-i386/bundles/lib/./libgmp.a(add_n.o) not allowed in slidable image collect2: ld returned 1 exit status
The package of 4.2.2 shipped with fink seems to work just fine (and doesn't appear to be doing anything special during configuration), so I'm not sure what the difference might be... does the process of using a bundle pass any arguments to the gmp configuration script?
Bill
On Aug 14, 2008, at 1:05 PM, Jonas Walldén @ Pike developers forum wrote:
Thanks for the comments. It's indeed the multiple libjpeg issue I'm taking a stab at here. Your fix predates 10.3 while my suggested tweak requires a 10.3+ ld feature (-undefined dynamic_lookup) so perhaps what seemed a necessity back then is better handled in this fashion nowadays. And who knows when the 10.0 compatibility mode disappears?
I can try this fix on a few more Macs before passing final judgement. I've got ppc32 on 10.4, x86 on 10.4 and x86_64 on 10.5 in Roxen's build farm.
Unfortunately I couldn't get the #pragma idea to work so it's not an option.
I should confess that I'm not using the bundles directory but a handbuilt Gmp 4.2.2. Nevertheless, going with a static module for Gmp solves my 10.5 issues.
To recap, I'd like to check in the following 7.8 changes:
gabrielle:7.8 $ cvs diff -u bin/smartlink Index: bin/smartlink =================================================================== RCS file: /pike/data/cvsroot/Pike/7.8/bin/smartlink,v retrieving revision 1.30 diff -u -r1.30 smartlink --- bin/smartlink 9 Mar 2006 20:57:19 -0000 1.30 +++ bin/smartlink 15 Aug 2008 09:22:42 -0000 @@ -192,6 +192,15 @@ # ;; #esac
+case "$UNAME" in + Darwin*) + # Needs to be 10.3 or better for ld to accept "-undefined dynamic_load" + export MACOSX_DEPLOYMENT_TARGET=10.3 + ;; + *) + ;; +esac + #echo $LINKER $LDOPTS
# exec $LINKER $LDOPTS
gabrielle:7.8 $ cvs diff -u src/configure.in Index: src/configure.in =================================================================== RCS file: /pike/data/cvsroot/Pike/7.8/src/configure.in,v retrieving revision 1.1067 diff -u -r1.1067 configure.in --- src/configure.in 31 Jul 2008 18:01:48 -0000 1.1067 +++ src/configure.in 15 Aug 2008 09:24:37 -0000 @@ -7610,7 +7610,9 @@ fi ;; Darwin*) - LDSHARED="$REALCC $CFLAGS -bundle -bind_at_load -flat_namespace -undefined suppress" + # Note that the following requires MACOSX_DEPLOYMENT_TARGET which is + # inited in bin/smartlink to 10.3. + LDSHARED="$REALCC $CFLAGS -bundle -bind_at_load -undefined dynamic_lookup" ;; IRIX*) if test "$GCC" = yes ; then
gabrielle:7.8 $ cvs diff -u src/modules/Gmp/Makefile.in Index: src/modules/Gmp/Makefile.in =================================================================== RCS file: /pike/data/cvsroot/Pike/7.8/src/modules/Gmp/Makefile.in,v retrieving revision 1.24 diff -u -r1.24 Makefile.in --- src/modules/Gmp/Makefile.in 4 May 2003 13:32:20 -0000 1.24 +++ src/modules/Gmp/Makefile.in 15 Aug 2008 09:23:35 -0000 @@ -9,7 +9,7 @@
CONFIG_HEADERS=@CONFIG_HEADERS@
-@dynamic_module_makefile@ +@static_module_makefile@
# UnixWare make needs help to find the source file... mpq.o: $(SRCDIR)/mpq.c
The first two updates dynamic module linking on Darwin to avoid -flat_namespace which is deprecated since many years. It requires OS X 10.3 or later but that's ok in my opinion.
The last one adresses building on OS X 10.5 where Gmp needs to be statically bound to overcome linker issues. The change would apply on all platforms but since bignums are an integral part of the Pike language it's not a concern.
Peter, any objections? Don't know if they qualify for any notes in CHANGES but I'd be happy to provide that too.
So this would break MacOS earlier than 10.3 then, or was it already broken? That is a bit of a problem since Opera will require one that supports older MacOS X, but unless it makes it worse I can fix it better later on.
You plan on distributing Pike 7.8 to people running OS X 10.2 or earlier? Does 7.8 from cvs compile and verify cleanly on 10.2 right now?
I suppose we can make the change conditional if the existing approach works on 10.2, but as you say it seems better to take care of later. I'll wait a bit longer to see if Bill or someone else with a Mac wants to verify my patches.
It's your lucky day. :-) Here's an updated patch which preserves the old behavior unless you're running 10.3 or newer.
gabrielle:7.8 $ cvs diff -u bin/smartlink src/configure.in Index: bin/smartlink =================================================================== RCS file: /pike/data/cvsroot/Pike/7.8/bin/smartlink,v retrieving revision 1.30 diff -u -r1.30 smartlink --- bin/smartlink 9 Mar 2006 20:57:19 -0000 1.30 +++ bin/smartlink 15 Aug 2008 12:18:56 -0000 @@ -192,6 +192,15 @@ # ;; #esac
+case "$UNAME" in + Darwin\ [7-9]*|Darwin\ [1-9][0-9]*) + # Needs to be 10.3 or better for ld to accept "-undefined dynamic_lookup" + export MACOSX_DEPLOYMENT_TARGET=10.3 + ;; + *) + ;; +esac + #echo $LINKER $LDOPTS
# exec $LINKER $LDOPTS Index: src/configure.in =================================================================== RCS file: /pike/data/cvsroot/Pike/7.8/src/configure.in,v retrieving revision 1.1067 diff -u -r1.1067 configure.in --- src/configure.in 31 Jul 2008 18:01:48 -0000 1.1067 +++ src/configure.in 15 Aug 2008 12:18:56 -0000 @@ -7610,7 +7610,19 @@ fi ;; Darwin*) - LDSHARED="$REALCC $CFLAGS -bundle -bind_at_load -flat_namespace -undefined suppress" + case "`uname -r`" in + [1-6].*) + # Mac OS X prior to 10.3 need -flat_namespace to support dynamic modules + LDSHARED="$REALCC $CFLAGS -bundle -bind_at_load -flat_namespace -undefined suppress" + ;; + *) + # 10.3 or newer take advantage of two-level namespaces to avoid + # symbol collisions for e.g. libjpeg which is referenced from both + # _Image_JPEG and _Image_TIFF. It requires MACOSX_DEPLOYMENT_TARGET + # which is initialized in bin/smartlink to 10.3. + LDSHARED="$REALCC $CFLAGS -bundle -bind_at_load -undefined dynamic_lookup" + ;; + esac ;; IRIX*) if test "$GCC" = yes ; then
I have no idea. It's off by default so I'll gladly leave the porting of my bin/smartlink addition to the person that enables it. :-)
Your changes seem to solve my problems... I think the trick was making Gmp a static module (which makes sense anyhow given its ubiquity)
I'll try the patch against the latest in CVS so that I can check out the module building situation.
Bill
On Aug 15, 2008, at 10:15 AM, Jonas Walldén @ Pike developers forum wrote:
I have no idea. It's off by default so I'll gladly leave the porting of my bin/smartlink addition to the person that enables it. :-)
I was about to say that it should apply cleanly to 7.8 from cvs, but now Grubba switched from bin/smartlink to src/smartlink.c without any consensus here so avoid src/configure.in r1.1068 for the moment.
I really don't like to see that type of wild fixes go in without even considering the consequences. Grubba, what platforms did you verify this optimization on? Better compile speed is rather low on the priority list in my mind.
bin/smartlink has had a total of two small patches since 7.7.3, one of which hadn't been ported to smartlink.c. Fixed.
How will smartlink /and/ smartlink.c be tested in paralell in the future?
well, they have not been tested in paralell in the past (unless you count the stable branches)
is there a configure switch? then then just set up your pikefarm client to try both.
greetings, martin.
Apparently, there is a "--disable-smartlink-binary" to force the use of the script.
By the way, why does smartlink.c look in $PATH itself instead of just using execvp?
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Really? Pike itself uses execvp().
Then there would be no reason to make smartlink more portable than pike itself, I'd say, and we can use execvp() there as well.
Or conversly, to make Pike less portable than smartlink. :-) But I also think we should go with execvp until we have a machine in xenofarm which fails the testsuite on execvp being missing/buggy.
Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote:
Probably because execv(2) is more portable.
According to my (old) stats, execve() is the most portable one.
But with srb's latest patch it's broken again (gcc 4.0.1 on OS X):
configure:9308: checking whether smartlink compiles Compiling smartlink: gcc -o smartlink -g -mcpu=970 -mtune=970 -I. /home/jonasw/pike/7.8/src/smartlink.c 2>&5 /home/jonasw/pike/7.8/src/smartlink.c: In function 'isexecutable': /home/jonasw/pike/7.8/src/smartlink.c:77: error: invalid operands to binary &
And how does one duplicate the uname()-dependent choices that can be found in the script version? Is it just the AC_DEFINEs in configure.in and acconfig.h?
Jonas Walld?n @ Pike developers forum wrote:
But with srb's latest patch it's broken again (gcc 4.0.1 on OS X):
configure:9308: checking whether smartlink compiles Compiling smartlink: gcc -o smartlink -g -mcpu=970 -mtune=970 -I. /home/jonasw/pike/7.8/src/smartlink.c 2>&5 /home/jonasw/pike/7.8/src/smartlink.c: In function 'isexecutable': /home/jonasw/pike/7.8/src/smartlink.c:77: error: invalid operands to binary &
Just a quick guess, it lacks some of the executable-bits macros? I'll throw in another fix to make the fix more portable.
Stephen R. van den Berg wrote:
Jonas Walld?n @ Pike developers forum wrote:
But with srb's latest patch it's broken again (gcc 4.0.1 on OS X):
I don't see this happening in Pikefarm, don't we have any MacOS X in there?
Jonas Walld?n @ Pike developers forum wrote:
I get exactly the same error on a Linux box as well.
Erm... Strange. Doe inserting this above the function help?
#ifndef S_IXUSR #define S_IXUSR 0100 #define S_IXGRP 0010 #define S_IXOTH 0001 #endif
http://pike.ida.liu.se/generated/pikefarm/7.8/31_2/configlogs.txt
Search for first occurence of "smartlink.c":
configure:6854: checking whether smartlink compiles Compiling smartlink: ccache gcc -o smartlink -g -O2 -falign-jumps=2 -ftracer -mpreferred-stack-boundary=2 -pipe -I. /var/src/xenofarm/pike-devel/aristoteles.cuci.nl/buildtmp/Pike-v7.8-snapshot/src/smartlink.c 2>&5 /var/src/xenofarm/pike-devel/aristoteles.cuci.nl/buildtmp/Pike-v7.8-snapshot/src/smartlink.c: In function 'isexecutable': /var/src/xenofarm/pike-devel/aristoteles.cuci.nl/buildtmp/Pike-v7.8-snapshot/src/smartlink.c:77: error: invalid operands to binary & (have 'struct stat' and 'int') configure:6862: result: no - use the sh script
Jonas Walld?n @ Pike developers forum wrote:
http://pike.ida.liu.se/generated/pikefarm/7.8/31_2/configlogs.txt
Search for first occurence of "smartlink.c":
configure:6854: checking whether smartlink compiles Compiling smartlink: ccache gcc -o smartlink -g -O2 -falign-jumps=2 -ftracer -mpreferred-stack-boundary=2 -pipe -I. /var/src/xenofarm/pike-devel/aristoteles.cuci.nl/buildtmp/Pike-v7.8-snapshot/src/smartlink.c 2>&5 /var/src/xenofarm/pike-devel/aristoteles.cuci.nl/buildtmp/Pike-v7.8-snapshot/src/smartlink.c: In function 'isexecutable': /var/src/xenofarm/pike-devel/aristoteles.cuci.nl/buildtmp/Pike-v7.8-snapshot/src/smartlink.c:77: error: invalid operands to binary & (have 'struct stat' and 'int') configure:6862: result: no - use the sh script
Sorry, found it, I think. Rusty syscall-memory I guess, this is what the code should have looked like in the first place:
diff --git a/src/smartlink.c b/src/smartlink.c index d7387c0..0435511 100644 --- a/src/smartlink.c +++ b/src/smartlink.c @@ -74,7 +74,8 @@ static int isexecutable(char *file) { struct stat stbuf;
- return !stat(file, &stbuf) && !S_ISDIR(stbuf) + return !stat(file, &stbuf) + && !S_ISDIR(stbuf.st_mode) && stbuf.st_mode&(S_IXUSR|S_IXGRP|S_IXOTH); }
Does that solve the problem?
Yes, compiles on my Mac at least. IMHO it wouldn't hurt with some extra whitespace surrounding the & and | operators either.
Jonas Walld?n @ Pike developers forum wrote:
Yes, compiles on my Mac at least. IMHO it wouldn't hurt with some extra whitespace surrounding the & and | operators either.
Fixed and committed.
And how does one duplicate the uname()-dependent choices that can be found in the script version? Is it just the AC_DEFINEs in configure.in and acconfig.h?
Since no-one provided any hints you've also all but forfeited your chance to complain about this patch. :-)
It fixes OS X crashes involving Image.JPEG (any possibly other modules) which is broken due to conflicting library symbols. The patch preserves the old behavior on 10.2 or older. I've tested on macosx_ppc32 (10.4), macosx_x86_64 (10.5) and a rhel5_x86_64. Ok to commit in 7.8?
lipton:7.8 $ cvs diff -u src/configure.in src/acconfig.h src/smartlink.c bin/smartlink Index: src/configure.in =================================================================== RCS file: /pike/data/cvsroot/Pike/7.8/src/configure.in,v retrieving revision 1.1068 diff -u -r1.1068 configure.in --- src/configure.in 15 Aug 2008 12:59:51 -0000 1.1068 +++ src/configure.in 19 Aug 2008 09:45:18 -0000 @@ -841,6 +841,22 @@ ;; esac
+# Smartlink needs to know if OS X uses flat or two-level namespace +if test "$pike_cv_sys_os" = "Darwin" ; then + AC_MSG_CHECKING([for Darwin linker namespace]) + case "`uname -r`" in + [1-6].*) + AC_MSG_RESULT([flat (10.2 or older)]) + pike_cv_osx_twolevel_namespace=no + ;; + *) + AC_DEFINE(USE_OSX_TWOLEVEL_NAMESPACE) + AC_MSG_RESULT([two-level (10.3 or newer)]) + pike_cv_osx_twolevel_namespace=yes + ;; + esac +fi +
# Fix a smartlink SMARTLINK="$BUILDDIR/smartlink" @@ -7612,7 +7628,16 @@ fi ;; Darwin*) - LDSHARED="$REALCC $CFLAGS -bundle -bind_at_load -flat_namespace -undefined suppress" + if test "$pike_cv_osx_twolevel_namespace" = yes ; then + # 10.3 or newer take advantage of two-level namespaces to avoid + # symbol collisions for e.g. libjpeg which is referenced from both + # _Image_JPEG and _Image_TIFF. It requires MACOSX_DEPLOYMENT_TARGET + # which is initialized in smartlink to 10.3. + LDSHARED="$REALCC $CFLAGS -bundle -bind_at_load -undefined dynamic_lookup" + else + # Mac OS X prior to 10.3 need -flat_namespace to support dynamic modules + LDSHARED="$REALCC $CFLAGS -bundle -bind_at_load -flat_namespace -undefined suppress" + fi ;; IRIX*) if test "$GCC" = yes ; then Index: src/acconfig.h =================================================================== RCS file: /pike/data/cvsroot/Pike/7.8/src/acconfig.h,v retrieving revision 1.158 diff -u -r1.158 acconfig.h --- src/acconfig.h 29 Mar 2008 11:50:55 -0000 1.158 +++ src/acconfig.h 19 Aug 2008 09:45:18 -0000 @@ -124,6 +124,9 @@ /* Define this if your ld doesn't have an option to set the run path */ #undef USE_LD_LIBRARY_PATH
+/* Define this on OS X to get two-level namespace support in ld */ +#undef USE_OSX_TWOLEVEL_NAMESPACE + /* Define if your tcc supports #pragma TenDRA longlong type allow. */ #undef HAVE_PRAGMA_TENDRA_LONGLONG
Index: src/smartlink.c =================================================================== RCS file: /pike/data/cvsroot/Pike/7.8/src/smartlink.c,v retrieving revision 1.20 diff -u -r1.20 smartlink.c --- src/smartlink.c 18 Aug 2008 14:31:33 -0000 1.20 +++ src/smartlink.c 19 Aug 2008 09:45:18 -0000 @@ -389,6 +389,14 @@ } }
+#ifdef USE_OSX_TWOLEVEL_NAMESPACE + /* Mac OS X needs to be 10.3 or better for ld to accept + "-undefined dynamic_lookup" */ + if (putenv("MACOSX_DEPLOYMENT_TARGET=10.3")) { + fatal("Out of memory (8)!\n"); + } +#endif + execv(argv[1], new_argv); fprintf(stderr, "%s: exec of %s failed!\n", argv[0], argv[1]); exit(1); Index: bin/smartlink =================================================================== RCS file: /pike/data/cvsroot/Pike/7.8/bin/smartlink,v retrieving revision 1.30 diff -u -r1.30 smartlink --- bin/smartlink 9 Mar 2006 20:57:19 -0000 1.30 +++ bin/smartlink 19 Aug 2008 09:45:18 -0000 @@ -192,6 +192,15 @@ # ;; #esac
+case "$UNAME" in + Darwin\ [7-9]*|Darwin\ [1-9][0-9]*) + # Needs to be 10.3 or better for ld to accept "-undefined dynamic_lookup" + export MACOSX_DEPLOYMENT_TARGET=10.3 + ;; + *) + ;; +esac + #echo $LINKER $LDOPTS
# exec $LINKER $LDOPTS
Looks fine to me. But for 7.9 I think we should have a smartlink.in and use the results of the configure tests rather than duplicating them in the script. (This goes for all the tests of course, not just the "twolevel namespace" test.)
Good, now committed in 7.8.
I'll commit the GMP build fix too which I posted last week (and which Bill verified) in a moment.
I just fixed another bug in smartlink.c: When it filtered away -g and -ggdb3, it also filtered away argv[0]. gcc was quite puzzled to find "-DHAVE_CONFIG_H" as argv[0]...
I can confirm that this alpha builds on OSX-Intel 10.5; though I already had gmp and nettle installed, so it's not testing the bundles (I believe there was something I had to do to the gmp build to get it to compile, similar to the problems Jonas had).
I did notice the following problems while running pike -x module:
1. include/pike/precompile.sh is not installed with correct permission. I'm not sure if the installer script should handle that or if it's some other problem.
2. precompile.sh is still using include/pike/precompile.pike, which contains an invalid inherit.
3. Verify fails because:
/Users/hww3/Downloads/Pike-v7.8.8/build/darwin-9.2.1-i386/pike - DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/Users/hww3/Downloads/Pike- v7.8.8/build/darwin-9.2.1-i386/master.pike -Mplib/modules /usr/local/ pike/7.8.8/include/pike/test_pike.pike testsuite
Note the location of the pike binary and master are the pike build location that I previously removed, while the script itself is being run from the correct (installed) location.
This functionality worked formerly; since these regressions seem to be recent, I'm hesitant to do something about them myself, as there was a good bit of work done. Anyone else want to claim them?
Bill
On Aug 13, 2008, at 7:25 PM, Peter Bortas @ Pike developers forum wrote:
7.8 alpha 2 is avilable as
http://pike.ida.liu.se/pub/pike/alpha/7.8.8/Pike-v7.8.8.tar.gz
It's not a beta because the changelog isn't complete. Other than that I know of no release blockers.
- include/pike/precompile.sh is not installed with correct
permission. I'm not sure if the installer script should handle that or if it's some other problem.
See also https://community.roxen.com/crunch/show_bug.cgi?id=4564
Yes. It's a problem with the installer. I'll fix it later today if no one beats me to it. Since it's not only AIDO internal modules that have the problem I'll promote it to blocker.
pike-devel@lists.lysator.liu.se
-
Bill Welliver -
H. William Welliver III
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Jonas Walld�n ＠ Pike developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Bähr -
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Peter Bortas ＠ Pike developers forum
-
Stephen R. van den Berg