Re: [Fink-devel] Fwd: [Pythonmac-SIG] CXX/Numeric problem on MacOSX (was building vpython on MacOSX)
Nope.. no help. It's looking like the problem might be that errno is being set in one thread, and detected in another. Does that sound possible? thanks, -steve On Sunday, February 24, 2002, at 04:55 PM, Gordon Messmer wrote: > Attempting to write to a full, non-blocking fd might do it. What > happens if you direct stdout to /dev/null? > > > On Sun, 2002-02-24 at 09:46, Steve Spicklemire wrote: >> Hi Folks, >> >> I thought I'd try the fink list this is a follow-up to a question I >> posted yesterday. I've been digging a little deeper. What sorts of >> things cause "resource temporarily unavailable"? >> >>> >>> import visual >>> >>> import sys >>> >>> print len(sys.argv) >>> >>> class foo: >>> pass >>> >>> if len(sys.argv)<2: >>> band = foo() >>> print "band is a simple class" >>> else: >>> print "band is a curve" >>> band = visual.curve() >>> >>> >>> band.foo1 = visual.array(10*[1],visual.Float) >>> band.foo2 = visual.array(10*[2],visual.Float) >>> >>> i=0 >>> >>> while 1: >>> i += 1 >>> print "iter",i, >>> bleah = band.foo2 - band.foo1 >>> if visual.sum(bleah*bleah) != 10.0: >>> print "Hmm. the math is wrong" >>> sys.stdout.flush() > > ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Puzzling issue with CDPATH / libtool / gdk-pixbuf
On Sunday, February 24, 2002, at 04:28 PM, David R. Morrison wrote: > I have separate binaries for /bin/sh and /bin/zsh, although they are > identical in size (449616) and date (Dec 31). Presumably they were > installed by the 10.1.3 upgrade. Sizes are the same here. I'm running 10.1.2 Matthias ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] foo-bin (was Re: control-center problem solved)
I've just thought of something which might help with backward-compatibility. What if the package foo (which contains headers) were given a dependency Depends: foo-shlibs (= current.version), foo-bin That way, at least when you are upgrading foo-bin will get installed. This doesn't solve things completely, because users could still remove foo-bin and get into trouble, but it least it minimizes the chances that things break during the transition period. Anybody see drawbacks to this? -- Dave ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] control-center problem solved
Hi Martin. I'm sorry that the backward-compatibility has not been perfect. But let me remind you about what we are solving with the splitting up of packages. An excellent example is provided by gal. gal is under rapid development, and new versions (gal-17, gal-18, gal-19) are *not* backward-compatible. So as you probably know, each time Masanori has updated to the latest version, every package depending on gal had to be rebuilt. The solution (it is the same solution that debian uses) is to provide a package which contains only the gal-18 or gal-19 or gal-20 shared libraries, and to guarantee that everything in that package has the number 18, 19 or 20 somewhere in its pathname. That way, all of these libraries can be installed simultaneously, and you can use various other packages which depend on them, without rebuilding (until the maintainer of the other package updates from gal-19 to gal-20, say). Now to get the building to work out right, there has to be a second package for each of these, which contains headers and also a key symbolic link associating the unnumbered gal library to the correctly numbered one. (That way, at link time the correct version of the library is linked in.) These packages all conflict with each other, so we can't allow any other package to depend on them. To try to get backward-compatibility to work, we are using the original package name for this header package, and the "-shlibs" name for the library package. The difficulty comes when something else, like binaries, also needs to be installed at runtime. That's when we get to a third package, and I agree that it is awkward, especially for backward-compatibility. We need the third package, though, because the binaries won't have the version number in their pathnames so they can't go with the libraries, and other things might depend on them so they can't go with the headers. I guess we need to be particularly careful in these cases that we get other packages changed ASAP to include the dependence on foo-bin. In fact, a conservative strategy would be to introduce a package foo-bin which was basically empty, convince all other developers to include it as a dependency, and *then* do the pacakge-splitting business. But that really shouldn't be necessary, we should be able to fix these things as they come up. -- Dave ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] control-center problem solved
OK, at least one of the recent mysteries of mine is solved: control-center rebuilds now again for me. The problem was that orbit-bin was not installed. The reason is clear: nothing depends on it. So its contents that were in the orbit package before are removed. No backward compatibility. Now I can see that I have plenty of other packages where foo and foo-shlibs are installed but foo-bin is not. No wonder that a lot of things break. I think this triple-split is evil. -- Martin ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] sed "Unterminated `s' command"
Benjamin Reed [[EMAIL PROTECTED]] wrote:
> s%@ACLOCAL@%${SHELL} /tmp/squid-2.5.PRE4/cfgaux
> /tmp/squid-2.5.PRE4/cfgaux/missing --run aclocal%g
>
> ...which are supposed to be on one line.
I fixed this by redirecting the output of the 'cd' command to
/dev/null. =)
On to the next annoying question. ;) I would prefer squid doesn't run as
rooot; should I add an account for it in the passwd-* package, or is it
enough to just run it under the 'nobody' user?
--
Ben Reed a.k.a. Ranger Rick ([EMAIL PROTECTED])
http://defiance.dyndns.org/ / http://radio.scenespot.org/
...if humanoids eat chicken, then obviously they'd eat their own
species. Otherwise they'd just be picking on the chickens. -- Kryten
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Puzzling issue with CDPATH / libtool / gdk-pixbuf
"David R. Morrison" <[EMAIL PROTECTED]> writes: > installed by the 10.1.3 upgrade. I don't know how to check the version > number of sh or zsh, which Matthias said was 3.0.8 in his case. This should work: zsh -c 'echo $ZSH_VERSION' ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Puzzling issue with CDPATH / libtool / gdk-pixbuf
I have separate binaries for /bin/sh and /bin/zsh, although they are identical in size (449616) and date (Dec 31). Presumably they were installed by the 10.1.3 upgrade. I don't know how to check the version number of sh or zsh, which Matthias said was 3.0.8 in his case. -- Dave ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Puzzling issue with CDPATH / libtool / gdk-pixbuf
Peter O'Gorman wrote: > This sounds like an interesting enigma, please let us know if > you find the cause. I wonder if fink could somehow run in a > 'clean' shell. Did you upgrade to 10.1.3? -- Martin ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] sed "Unterminated `s' command"
Benjamin Reed wrote:
>
> I'm trying to make a package for squid, and it's got one small configure
> error. I swear I've seen something about this before but I can't for
> the life of me find any reference to it in the list archives.
>
> When I run configure, I end up with a bunch of lines like:
>
> creating Makefile
> sed: file conftest.s1 line 33: Unterminated `s' command
> creating lib/Makefile
> sed: file conftest.s1 line 33: Unterminated `s' command
>
> The problem is in config.status, I'm ending up with double-lines like:
>
> s%@ACLOCAL@%${SHELL} /tmp/squid-2.5.PRE4/cfgaux
> /tmp/squid-2.5.PRE4/cfgaux/missing --run aclocal%g
>
> ...which are supposed to be on one line.
The plot thickens...
This is exactly the same bug Matthias Neeracher was writing about! It's
zsh interpreting CDPATH differently from what it is supposed to.
Why does this reappear suddenly? It seemed to have disappeared last
September with OSX 10.1, and now it reappears with 10.1.3. Or is it a
regression in one of the auto* tools?
> Is there anything short of rerunning autoconf and friends I can do to
> make this work?
It would be interesting to see if it goes away if you rerun the auto
guys. I doubt it.
--
Martin
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Puzzling issue with CDPATH / libtool / gdk-pixbuf
Matthias Neeracher wrote: > > Trying to update my unstable packages at home, I run into problems with > gdk-pixbuf-shlibs-0.16.0-2 and gdk-pixbuf-0.16.0-3. Both of these > packages complained about not being able to find library `' (Yes, that's > an empty string). > I traced the build and found the following: > > - libtool is run by /bin/sh which on MacOS X is a link to zsh (3.0.8 on > my machine). > - libtool sets CDPATH to :, because in zsh, apparently CDPATH is > considered "set" although it doesn't show up in printenv. > - This setting, which is supposed to SUPPRESS printing the destination > directory for cd with relative pathnames, actually FORCES printing the > destination with zsh. > - Therefore, the line > absdir=`cd "$dir" && pwd` > sets absdir to contain TWO copies of the directory path, not one. > > This eventually produces the error I saw. I remember discussions of this last September on the darwin-devel list: http://lists.apple.com/archives/darwin-development/2001/Sep/12.html, and I found also a message on the automake list by ChrisP: http://www.mail-archive.com/automake@gnu.org/msg03908.html I thought this had been fixed long since. > after running configure. But I'm still puzzled. The libtool looks > exactly like all the other libtools in other fink > packages. Why does this problem not occur with other packages? And why, > for that matter, has notbody else apparently had problems with > gdk-pixbuf? There is something funny going on with several gnome packages that built correctly some days ago and don't any more now. I had the "library `' " bug in rebuilding sawfish that I had rebuilt some days before without problem. There it could be avoided by removing some library search path from esound-config. I cannot rebuild control-center. And I had updated gdk-pixbuf and gdk-pixbuf-shlibs on Feb-13, apparently without problem. When I try it now, I don't get Matthias' bug, but another one that seems to come from -no-cpp-precomp not being transmitted to make: cc -O3 -I.. -I.. -I/sw/include/gnome-1.0 -DNEED_GNOMESUPPORT_H -I/sw/lib/gnome-libs/include -I/sw/include -I/sw/include/gtk-1.2 -I/sw/include/glib-1.2 -I/sw/lib/glib/include -I/usr/X11R6/include -c gdk-pixbuf-scan.c -fno-common -DPIC -o gdk-pixbuf-scan.lo gdk-pixbuf-scan.c:1317: bad macro argument list gdk-pixbuf-scan.c:1317: bad macro argument list gdk-pixbuf-scan.c:1317: bad macro argument list gdk-pixbuf-scan.c:1317: bad macro argument list cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode Compilation of scanner failed make[2]: *** [scan-build.stamp] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive-am] Error 2 ### make failed, exit code 2 Failed: compiling gdk-pixbuf-0.16.0-3 failed The file gdk-pixbuf-scan.c doesn't even have 1317 lines, only about 680, and if I put -no-cpp-precomp there, it compiles (but fails later on with a similar error elsewhere). Strange... Something must have changed, can it be OSX 10.1.3? -- Martin ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Puzzling issue with CDPATH / libtool / gdk-pixbuf
Hi, I don't have any problems with gdk-pixbuf, which is strange, because my /bin/sh is zsh too (Apple supplied hard link to /bin/zsh). Makes me wonder if you have some env vars set which may affect things or something else to do with your setup. It is odd that you and I get different results on the same package using the same shell.. This sounds like an interesting enigma, please let us know if you find the cause. I wonder if fink could somehow run in a 'clean' shell. Peter On Monday, February 25, 2002, at 06:49 AM, Matthias Neeracher wrote: > Trying to update my unstable packages at home, I run into > problems with gdk-pixbuf-shlibs-0.16.0-2 and gdk- > pixbuf-0.16.0-3. Both of these packages complained about not > being able to find library `' (Yes, that's an empty string). >absdir=`cd "$dir" && pwd` > sets absdir to contain TWO copies of the directory path, not one. > > after running configure. But I'm still puzzled. The libtool > looks exactly like all the other libtools in other fink > packages. Why does this problem not occur with other packages? > And why, for that matter, has notbody else apparently had > problems with gdk-pixbuf? ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] sed "Unterminated `s' command"
I'm trying to make a package for squid, and it's got one small configure
error. I swear I've seen something about this before but I can't for
the life of me find any reference to it in the list archives.
When I run configure, I end up with a bunch of lines like:
creating Makefile
sed: file conftest.s1 line 33: Unterminated `s' command
creating lib/Makefile
sed: file conftest.s1 line 33: Unterminated `s' command
The problem is in config.status, I'm ending up with double-lines like:
s%@ACLOCAL@%${SHELL} /tmp/squid-2.5.PRE4/cfgaux
/tmp/squid-2.5.PRE4/cfgaux/missing --run aclocal%g
...which are supposed to be on one line.
Is there anything short of rerunning autoconf and friends I can do to
make this work?
--
Ben Reed a.k.a. Ranger Rick ([EMAIL PROTECTED])
http://defiance.dyndns.org/ / http://radio.scenespot.org/
...if humanoids eat chicken, then obviously they'd eat their own
species. Otherwise they'd just be picking on the chickens. -- Kryten
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Fwd: [Pythonmac-SIG] CXX/Numeric problem on MacOSX(was building vpython on MacOSX)
Attempting to write to a full, non-blocking fd might do it. What happens if you direct stdout to /dev/null? On Sun, 2002-02-24 at 09:46, Steve Spicklemire wrote: > Hi Folks, > > I thought I'd try the fink list this is a follow-up to a question I > posted yesterday. I've been digging a little deeper. What sorts of > things cause "resource temporarily unavailable"? > > > > > import visual > > > > import sys > > > > print len(sys.argv) > > > > class foo: > > pass > > > > if len(sys.argv)<2: > > band = foo() > > print "band is a simple class" > > else: > > print "band is a curve" > > band = visual.curve() > > > > > > band.foo1 = visual.array(10*[1],visual.Float) > > band.foo2 = visual.array(10*[2],visual.Float) > > > > i=0 > > > > while 1: > > i += 1 > > print "iter",i, > > bleah = band.foo2 - band.foo1 > > if visual.sum(bleah*bleah) != 10.0: > > print "Hmm. the math is wrong" > > sys.stdout.flush() signature.asc Description: This is a digitally signed message part
[Fink-devel] Puzzling issue with CDPATH / libtool / gdk-pixbuf
Trying to update my unstable packages at home, I run into problems with gdk-pixbuf-shlibs-0.16.0-2 and gdk-pixbuf-0.16.0-3. Both of these packages complained about not being able to find library `' (Yes, that's an empty string). I traced the build and found the following: - libtool is run by /bin/sh which on MacOS X is a link to zsh (3.0.8 on my machine). - libtool sets CDPATH to :, because in zsh, apparently CDPATH is considered "set" although it doesn't show up in printenv. - This setting, which is supposed to SUPPRESS printing the destination directory for cd with relative pathnames, actually FORCES printing the destination with zsh. - Therefore, the line absdir=`cd "$dir" && pwd` sets absdir to contain TWO copies of the directory path, not one. This eventually produces the error I saw. It was not very difficult to get the packages to build by simply putting in a line perl -i -ne 'print unless /CDPATH/' libtool ltconfig ltmain.sh after running configure. But I'm still puzzled. The libtool looks exactly like all the other libtools in other fink packages. Why does this problem not occur with other packages? And why, for that matter, has notbody else apparently had problems with gdk-pixbuf? Matthias ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Perl Packages & Diff usage
On Sunday, February 24, 2002, at 08:20 , David R. Morrison wrote: > Kyle Moffett <[EMAIL PROTECTED]> wrote: > >> On Sunday, February 24, 2002, at 07:25 , Jeff Whitaker wrote: the .so for A::R and A::C both statically link to libapreq, which should internally bind the entry points between the A::R/A::C and libapreq libs, and it does on every platform including Apple. However, on Apple, the entry points are also *published*, so when both .so's are pulled in, you get a duplicate on the libapreq entry points! I'm not smart enough to know how to turn that off. >>> >>> Randall: I think setting the environment variable >>> DYLD_FORCE_FLAT_NAMESPACE may fix this. At least it has for me in >>> similar >>> situations with the python interpreter. >> >> Unfortunately, this tends to break other packages that need the two >> level namespace (Grrr.) > > How about linking with the -force_flat_namespace option? Does that > help? Will try, that goes in LDFLAGS, right? Thanks, Kyle Moffett ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Fwd: [Pythonmac-SIG] CXX/Numeric problem on MacOSX (was building vpython on MacOSX)
Hi Folks, I thought I'd try the fink list this is a follow-up to a question I posted yesterday. I've been digging a little deeper. What sorts of things cause "resource temporarily unavailable"? thanks, -steve Begin forwarded message: > From: Steve Spicklemire <[EMAIL PROTECTED]> > Date: Sun Feb 24, 2002 12:41:42 PM America/Indianapolis > To: Steve Spicklemire <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: [Pythonmac-SIG] CXX/Numeric problem on MacOSX (was > building vpython on MacOSX) > > Hi (again), > > OK.. I found out that the error I'm getting is (reproducibly) actually > "error 35" described in /usr/include/sys/errno.h as: > > #define EAGAIN 35 /* Resource temporarily > unavailable */ > #ifndef _POSIX_SOURCE > #define EWOULDBLOCK EAGAIN /* Operation would block */ > > so.. it's saying that this operation would block or is temporarily > unavailable. Why? Any idea? > > thanks, > -steve > > On Sunday, February 24, 2002, at 09:35 AM, Steve Spicklemire wrote: > >> Diggin around I find that this error is generated in the "ufuncmodule" >> of Numeric. If I try to debug this I get to. >> >> The message comes from the math_error() function if ufuncobject, where >> I set a breakpoint. >> >> Breakpoint 2, math_error () at Src/ufuncobject.c:407 >> (gdb) print errno >> $1 = >> >> most unhelpful! >> >> On Sunday, February 24, 2002, at 09:35 AM, Steve Spicklemire wrote: > > Hi MacPython Folks (and Paul Dubois), > > Sorry for bothering you all again, but I'm getting closer to > sorting this out, but I think I need another hint. I've got vpython to > build on MacOSX, and it runs.. mostly. VPython makes heavy use of the > Numeric module, and also uses Paul Dubois' CXX extension class system > for creating python objects with c++. I'm an expert on neither, though > I have used the Numeric a fair amount. > > Below is a simple program that shows the problem. "visual" is the > module that contains all the vpython stuff, and it does "from Numeric > import *" so that all the Numeric code is also in the visual module. It > also imports the cvisualmodule, built on Paul's CXX extension system. > There is magic in visual.py that calls the correct constructor from > cvisualmodule when certain functions in the visual namespace are called > (e.g., curve()). If I run this program with no command line arguments, > "band" is a simple instance of the dummy class "foo". If I run with a > command line argument, "band" is an instance of a "curve" object from > the cvisualmodule extension. The program dies no matter what binary > operation I perform on two arrays, subtraction, addition, etc. > Multiplication by a constant doesn't show this problem however, so it's > something in the use of two arrays. > > If band is a simple instance this program runs forever (well.. for > a really long time). > > If band is an instance of a curve object, this program fails after an > indeterminate number of iterations (from tens to thousands, with no > clear cause). I get e.g., > > [vh10-15:~/Development/vpython/cvisual] steve% python test_wave2.py 1 > Visual-2001-12-30 > 2 > band is a curve > iter 1 iter 2 iter 3 iter 4 iter 5 iter 6 iter 7 iter 8 iter 9 iter 10 > iter 11 iter 12 iter 13 iter 14 iter 15 iter 16 iter 17 iter 18 iter 19 > iter 20 iter 21 iter 22 iter 23 iter 24 iter 25 iter 26 iter 27 iter 28 > iter 29 iter 30 iter 31 iter 32 iter 33 iter 34 iter 35 iter 36 iter 37 > iter 38 iter 39 iter 40 iter 41 iter 42 iter 43 iter 44 iter 45 iter 46 > iter 47 iter 48 iter 49 iter 50 iter 51 iter 52 iter 53 iter 54 iter 55 > iter 56 iter 57 iter 58 iter 59 iter 60 iter 61 iter 62 iter 63 iter 64 > iter 65 iter 66 iter 67 iter 68 iter 69 iter 70 iter 71 iter 72 iter 73 > iter 74 iter 75 iter 76 iter 77 iter 78 iter 79 iter 80 iter 81 iter 82 > iter 83 iter 84 iter 85 iter 86 iter 87 iter 88 iter 89 iter 90 iter 91 > iter 92 iter 93 iter 94 iter 95 iter 96 iter 97 iter 98 iter 99 iter > 100 iter 101 iter 102 iter 103 iter 104 iter 105 iter 106 iter 107 iter > 108 iter 109 iter 110 iter 111 iter 112 iter 113 iter 114 iter 115 iter > 116 iter 117 iter 118 iter 119 iter 120 iter 121 iter 122 iter 123 iter > 124 iter 125 iter 126 iter 127 iter 128 iter 129 iter 130 iter 131 iter > 132 iter 133 iter 134 iter 135 iter 136 iter 137 iter 138 iter 139 iter > 140 iter 141 iter 142 iter 143 iter 144 iter 145 iter 146 iter 147 iter > 148 iter 149 iter 150 iter 151 iter 152 iter 153 iter 154 iter 155 iter > 156 iter 157 iter 158 iter 159 iter 160 iter 161 iter 162 iter 163 iter > 164 iter 165 iter 166 iter 167 iter 168 iter 169 > Traceback (most recent call last): > File "test_wave2.py", line 26, in ? > bleah = band.foo2 - band.foo1 > ValueError: unexpected math error > > > Diggin around I find that this error is generated in the "ufuncmodule" > of Numeric. If I try to debug this I get to. > > The message comes from the mat
Re: [Fink-devel] Perl Packages & Diff usage
Kyle Moffett <[EMAIL PROTECTED]> wrote: > On Sunday, February 24, 2002, at 07:25 , Jeff Whitaker wrote: > >> > >> the .so for A::R and A::C both statically link to libapreq, which > >> should internally bind the entry points between the A::R/A::C and > >> libapreq libs, and it does on every platform including Apple. > >> > >> However, on Apple, the entry points are also *published*, so when both > >> .so's are pulled in, you get a duplicate on the libapreq entry points! > >> I'm not smart enough to know how to turn that off. > >> > > > > Randall: I think setting the environment variable > > DYLD_FORCE_FLAT_NAMESPACE may fix this. At least it has for me in > > similar > > situations with the python interpreter. > > Unfortunately, this tends to break other packages that need the two > level namespace (Grrr.) How about linking with the -force_flat_namespace option? Does that help? ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Perl Packages & Diff usage
On Sunday, February 24, 2002, at 07:25 , Jeff Whitaker wrote: >> >> the .so for A::R and A::C both statically link to libapreq, which >> should internally bind the entry points between the A::R/A::C and >> libapreq libs, and it does on every platform including Apple. >> >> However, on Apple, the entry points are also *published*, so when both >> .so's are pulled in, you get a duplicate on the libapreq entry points! >> I'm not smart enough to know how to turn that off. >> > > Randall: I think setting the environment variable > DYLD_FORCE_FLAT_NAMESPACE may fix this. At least it has for me in > similar > situations with the python interpreter. Unfortunately, this tends to break other packages that need the two level namespace (Grrr.) Oh well, Kyle Moffett ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Perl Packages & Diff usage
> > the .so for A::R and A::C both statically link to libapreq, which > should internally bind the entry points between the A::R/A::C and > libapreq libs, and it does on every platform including Apple. > > However, on Apple, the entry points are also *published*, so when both > .so's are pulled in, you get a duplicate on the libapreq entry points! > I'm not smart enough to know how to turn that off. > Randall: I think setting the environment variable DYLD_FORCE_FLAT_NAMESPACE may fix this. At least it has for me in similar situations with the python interpreter. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX: (303)497-6449 NOAA/OAR/CDC R/CDC1Email : [EMAIL PROTECTED] 325 BroadwayWeb: www.cdc.noaa.gov/~jsw Boulder, CO, USA 80303-3328 Office : Skaggs Research Cntr 1D-124 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
