gnuplot-beta

Universal binaries for Mac

[Jeremy C. <jer...@gm...>]

Please excuse me for jumping in to this list.  I just downloaded
gnuplot 4.2 rc4 this morning and tried to compile using the
suggestions from Mojca, but it didn't work.  Since this project is
about to release a stable version I thought I would chime in.

I set the following before compiling:

export CFLAGS=3D'-arch i386 -arch ppc'
export LDFLAGS=3D'-arch i386 -arch ppc'
./configure --disable-dependency-tracking

Then when I did:

make

I got the following linking error:

$ make
make  all-recursive
Making all in config
make[2]: Nothing to be done for `all'.
Making all in m4
make[2]: Nothing to be done for `all'.
Making all in term
make[2]: Nothing to be done for `all'.
Making all in src
Making all in wxterminal
make[3]: Nothing to be done for `all'.
gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term
-DBINDIR=3D\"/usr/local/bin\"
-DX11_DRIVER_DIR=3D\"/usr/local/libexec/gnuplot/4.2\"
-DGNUPLOT_PS_DIR=3D\"/usr/local/share/gnuplot/4.2/PostScript\"
-DCONTACT=3D\"gnu...@li...\"
-DHELPFILE=3D\"/usr/local/share/gnuplot/4.2/gnuplot.gih\"   -arch i386
-ObjC -c alloc.c

=85

gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term
-DBINDIR=3D\"/usr/local/bin\"
-DX11_DRIVER_DIR=3D\"/usr/local/libexec/gnuplot/4.2\"
-DGNUPLOT_PS_DIR=3D\"/usr/local/share/gnuplot/4.2/PostScript\"
-DCONTACT=3D\"gnu...@li...\"
-DHELPFILE=3D\"/usr/local/share/gnuplot/4.2/gnuplot.gih\"   -arch i386
-ObjC -c version.c
g++  -g -O2  -arch i386 -o gnuplot  alloc.o axis.o breaders.o bitmap.o
color.o command.o contour.o datafile.o dynarray.o eval.o fit.o
gadgets.o getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o
internal.o interpol.o matrix.o misc.o mouse.o parse.o plot.o plot2d.o
plot3d.o pm3d.o readline.o save.o scanner.o set.o show.o specfun.o
standard.o stdfn.o tables.o term.o time.o unset.o util.o util3d.o
variable.o version.o   -lreadline  -lncurses  -lz   -laquaterm
-framework Foundation
/usr/bin/ld: warning multiple definitions of symbol _init_color
color.o definition of _init_color in section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libncurses.dylib(lib_color.o=
)
definition of _init_color
/usr/bin/ld: warning multiple definitions of symbol _set_term
term.o definition of _set_term in section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libncurses.dylib(lib_set_ter=
m.o)
definition of _set_term
/usr/bin/ld: Undefined symbols:
_remove_history
_rl_forced_update_display
_history_list
_rl_ding
_rl_complete_with_tilde_expansion
collect2: ld returned 1 exit status
make[3]: *** [gnuplot] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I have installed AquaTerm and everything else is left unchanged.  Can
someone help?  Has a Universal Binary been made available?
Thanks,
Jeremy

Re: Universal binaries for Mac

[Lars H. <lhe...@us...>]

[...]
> /usr/bin/ld: Undefined symbols:
> _remove_history
> _rl_forced_update_display
> _history_list
> _rl_ding
> _rl_complete_with_tilde_expansion
> collect2: ld returned 1 exit status
> make[3]: *** [gnuplot] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2

 This looks like you need to link with GNU readline. Probably a side effect
 of defaulting to GNU readline in the latest code (which I'm not convinced
 of for licensing reasons).

Re: Universal binaries for Mac

[Jeremy C. <jer...@gm...>]

On 1/25/07, Lars Hecking <lhe...@us...> wrote:
> [...]
> > /usr/bin/ld: Undefined symbols:
> > _remove_history
> > _rl_forced_update_display
> > _history_list
> > _rl_ding
> > _rl_complete_with_tilde_expansion
> > collect2: ld returned 1 exit status
> > make[3]: *** [gnuplot] Error 1
> > make[2]: *** [all-recursive] Error 1
> > make[1]: *** [all-recursive] Error 1
> > make: *** [all] Error 2
>
>  This looks like you need to link with GNU readline. Probably a side effect
>  of defaulting to GNU readline in the latest code (which I'm not convinced
>  of for licensing reasons).
>
Well I wish it was that easy.  I tried linking to the builtin
readline, that didn't work.  I downloaded and compiled/installed the
GNU readline and tried linking to that (by letting configure pick the
defauly and by explicitly selecting GNU readline) and that didn't work
either.  I get the same errors.

I have tried this on my MacBook Pro (Intel) and on an older PowerMac
G4.  Both running Tiger 10.4.8.  Any other suggestions?

Thanks,
Jeremy

ps. Sorry Lars, meant to post this to the list

Re: Universal binaries for Mac

[Petr M. <mi...@ph...>]

> ./configure --disable-dependency-tracking

What does that option mean? Try
	./configure

---
PM

Re: Universal binaries for Mac

[Ethan A M. <merritt@u.washington.edu>]

We had similar report on OSX problems with -rc3.
But in that case building with ./configure --with-readline=builtin
apparently worked.  See bug report 

http://sourceforge.net/tracker/index.php?func=detail&aid=1642845&group_id=2055&atid=102055

Please help us figure out whether this is 1 bug, or 2 bugs, or a 
general problem with gnu libreadline on OSX, or what.

	thanks

		Ethan

On Thursday 25 January 2007 08:08, Jeremy Conlin wrote:
> On 1/25/07, Lars Hecking <lhe...@us...> wrote:
> > [...]
> > > /usr/bin/ld: Undefined symbols:
> > > _remove_history
> > > _rl_forced_update_display
> > > _history_list
> > > _rl_ding
> > > _rl_complete_with_tilde_expansion
> > > collect2: ld returned 1 exit status
> > > make[3]: *** [gnuplot] Error 1
> > > make[2]: *** [all-recursive] Error 1
> > > make[1]: *** [all-recursive] Error 1
> > > make: *** [all] Error 2
> >
> >  This looks like you need to link with GNU readline. Probably a side effect
> >  of defaulting to GNU readline in the latest code (which I'm not convinced
> >  of for licensing reasons).
> >
> Well I wish it was that easy.  I tried linking to the builtin
> readline, that didn't work.  I downloaded and compiled/installed the
> GNU readline and tried linking to that (by letting configure pick the
> defauly and by explicitly selecting GNU readline) and that didn't work
> either.  I get the same errors.
> 
> I have tried this on my MacBook Pro (Intel) and on an older PowerMac
> G4.  Both running Tiger 10.4.8.  Any other suggestions?
> 
> Thanks,
> Jeremy
> 
> ps. Sorry Lars, meant to post this to the list
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Universal binaries for Mac

[Jeremy C. <jer...@gm...>]

On 1/25/07, Ethan A Merritt <merritt@u.washington.edu> wrote:
> We had similar report on OSX problems with -rc3.
> But in that case building with ./configure --with-readline=builtin
> apparently worked.  See bug report
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1642845&group_id=2055&atid=102055
>
>
I got it to work by doing the following

export CFLAGS='-arch i386'
export LDFLAGS='-arch i386'
./configure --with-readline=builtin

I also tried the gnu readline, but that didn't work.  Notice this is
not a universal binary!  It is only for intel macs.  I could not get
either builtin or gnu readline to work when compiling for both
architectures.

 Please help us figure out whether this is 1 bug, or 2 bugs, or a
> general problem with gnu libreadline on OSX, or what.
>
>         thanks
>
>                 Ethan
>
I'm not sure where the bug is.  I suspect this is only one bug noted
in the above bug report.  I wish I had more information to share

Thanks,
Jeremy

Re: Universal binaries for Mac

[Mojca M. <moj...@gm...>]

On 1/25/07, Jeremy Conlin wrote:
> Please excuse me for jumping in to this list.  I just downloaded
> gnuplot 4.2 rc4 this morning and tried to compile using the
> suggestions from Mojca, but it didn't work.  Since this project is
> about to release a stable version I thought I would chime in.

Please note that I'm a complete newbie on mac and in compiling/making
issues. I managed to create a new terminal, but I don't manage to deal
with compilation/installation issues.

Las tweek I've found the script which does "kind-of-bundling", but
there are quite some problems with it and I have no idea how to do
things properly (I know what I should do, but not how to do that).

Two tiny problems with that script:
- version is not fixed (config/MacOSX/createdist.sh)
- A file /usr/local/gwTeX/texmf.texlive/.../gnuplot.cfg (with the only
line which sets the font encoding to T1) gets included - the problem
is that if I gave that to someone, he might have TeX installed on
another location (for example: one month ago the default folder was
something else, but people might have fink's tetex or whatever else)

But there are more serious problems, like libraries. If I build
gnuplot with fink, the user who wants to use it need the same fink's
libraries installed to be able to use it. Simply adding "-static"
doesn't help since all the libraries on the system should be build
static and for both architectures I assume.


pdfTeX's svn repository also contain all the needed libraries, so
cross-compiling or building on a system without the needed libraries
is not an issue at all. With gnuplot it's like a nightmare to get all
the libraries properly. On linux distributions that's not a problem,
but on windows and mac it is. I only wish I had the knowledge how to
fix all that.

Without some mac developer who knows what he's doing, things will
never be sorted out properly for that platform. (I would also wish to
have the same kind of help as on windows, but I can't figure out what
flags to set for the compiler, so that gnuplot could launch "proper
help browser" instead of command-line version.)

I'll try to compile gnuplot without fink once I get home to see if I
get that problem. Just a thought: is it possible that "GNU readline"
would fail because the compiler/libraries are not exactly the same as
GNU?
(Sorry, I really don't know much about it, but when I got the computer
and tried to enable colors in "ls", I figured out that I needed the
GNU version of "ls"; the syntax/configuration didn't work with the
version that comes with mac by default - BSD.)

Mojca

Re: Universal binaries for Mac

[Per P. <per...@ma...>]

On Jan 25, 2007, at 19:30, Mojca Miklavec wrote:

> But there are more serious problems, like libraries. If I build
> gnuplot with fink, the user who wants to use it need the same fink's
> libraries installed to be able to use it.

Isn't that expected? Fink's job is to track dependencies and handle  
them for _you_.

> Simply adding "-static"
> doesn't help since all the libraries on the system should be build
> static and for both architectures I assume.

Well, -static won't help but of course you can statically link any  
required library which can be built as a static library.
As an example, in a binary release, static linking of readline (or  
using builtin) is a must.

For libs provided as part of OS X, always shared libs or  
"frameworks", we should use them.
Any other functionality which relies on non-standard libs[1] (from an  
OS X point of view) should be statically linked.

In fixing up the release script, we might as well do our homework  
properly and decide what should come from the system and what should  
be linked in statically (and what must be left out).

[1] D'oh! I just realized that the one and only non-standard  
*framework* required is AquaTerm.framework. Can't link statically  
from frameworks AFAIK. Maybe we should supply the AquaTerm package as  
a sub-package[2] of gnuplot to be automagically installed if necessary?

[2] Come to think of it, we could do that for other libs as well, but  
then again, we don't want to mess up people's computers do we? ;-)

Best,
Per

Re: Universal binaries for Mac

[Per P. <per...@ma...>]

On Jan 25, 2007, at 17:40, Ethan A Merritt wrote:

> We had similar report on OSX problems with -rc3.
> But in that case building with ./configure --with-readline=builtin
> apparently worked.  See bug report
>
> http://sourceforge.net/tracker/index.php? 
> func=detail&aid=1642845&group_id=2055&atid=102055
>
> Please help us figure out whether this is 1 bug, or 2 bugs, or a
> general problem with gnu libreadline on OSX, or what.
>

Hi all,
sorry for being late to the party, trying to catch up after we  
finally got back phone line last week and DSL-connection yesterday,  
after almost 8 weeks (long story involving moving and switching  
service providers... :-P ).

1) The readline issue is caused by someone at Apple having the  
"bright" idea to symlink /usr/lib/libreadline.dylib to /usr/lib/ 
libedit.dylib
(The reason for not including readline are license terms, only BSD/ 
LGPL/etc. in OS X not GPL)

However, using ./configure  --with-readline=/path/to/your/gnu/ 
libreadline should work if libreadline is installed somewhere.

2) The snapshot script: It is really crude, and currently only works  
on my machine. However, it was intended as a staring point for a tool  
to build properly packaged binary OS X releases from CVS or tarballs  
with a single command.
Besides TeX, you'll need Iceberg ( http://s.sudre.free.fr/Software/ 
Iceberg.html ) for it to work.
We should fix it to build Universal Binaries too, but it'll require  
someone with an Intel Mac for testing.

I'll update my gnuplot sources now, and have a look at (1).

/Per

Re: Universal binaries for Mac

[Jeremy C. <jer...@gm...>]

On 1/25/07, Per Persson <per...@ma...> wrote:
>
> On Jan 25, 2007, at 17:40, Ethan A Merritt wrote:
>
> > We had similar report on OSX problems with -rc3.
> > But in that case building with ./configure --with-readline=builtin
> > apparently worked.  See bug report
> >
> > http://sourceforge.net/tracker/index.php?
> > func=detail&aid=1642845&group_id=2055&atid=102055
> >
> > Please help us figure out whether this is 1 bug, or 2 bugs, or a
> > general problem with gnu libreadline on OSX, or what.
> >
>
> Hi all,
> sorry for being late to the party, trying to catch up after we
> finally got back phone line last week and DSL-connection yesterday,
> after almost 8 weeks (long story involving moving and switching
> service providers... :-P ).
>
> 1) The readline issue is caused by someone at Apple having the
> "bright" idea to symlink /usr/lib/libreadline.dylib to /usr/lib/
> libedit.dylib
> (The reason for not including readline are license terms, only BSD/
> LGPL/etc. in OS X not GPL)
>
> However, using ./configure  --with-readline=/path/to/your/gnu/
> libreadline should work if libreadline is installed somewhere.
>
> 2) The snapshot script: It is really crude, and currently only works
> on my machine. However, it was intended as a staring point for a tool
> to build properly packaged binary OS X releases from CVS or tarballs
> with a single command.
> Besides TeX, you'll need Iceberg ( http://s.sudre.free.fr/Software/
> Iceberg.html ) for it to work.
> We should fix it to build Universal Binaries too, but it'll require
> someone with an Intel Mac for testing.
>

I have an Intel Mac and am willing to test.  What should I do?

Jeremy

readline problems on OSX

[Ethan M. <merritt@u.washington.edu>]

On Thursday 25 January 2007 12:52, Per Persson wrote:
> 
> 1) The readline issue is caused by someone at Apple having the  
> "bright" idea to symlink /usr/lib/libreadline.dylib to /usr/lib/ 
> libedit.dylib
> (The reason for not including readline are license terms, only BSD/ 
> LGPL/etc. in OS X not GPL)
> 
> However, using ./configure  --with-readline=/path/to/your/gnu/ 
> libreadline should work if libreadline is installed somewhere.

Aha.  So gnuplot's configure script is correct, but OSX is lying to it.
Wonderful.  I don't think we can fix this on the gnuplot end, except
maybe by making a special case of OSX (which of course the 
autoconf tools do not want you to do).

On the bright side, does this mean that OSX contains a usable
version of libedit?  We were already experimenting with adding
that as a ./configure option, but couldn't find a copy of libedit that
actually worked :-(      

If OSX really does have a working version, then I suppose we could
test first for libedit, and only test for gnu readline after that.
That might work, and would not be specific to OSX.   
But only if libedit actually works, of course.

> I'll update my gnuplot sources now, and have a look at (1).

Great.  While you're at it, maybe you could have a look at  patchset 
#1504831 which attempts to use libedit as an alternative to readline.
Note the warning about a name conflict with routine term_init().

	thanks for the insight!

Re: readline problems on OSX

[Per P. <per...@ma...>]

On Jan 25, 2007, at 22:09, Ethan Merritt wrote:

> Aha.  So gnuplot's configure script is correct, but OSX is lying to  
> it.
> Wonderful.  I don't think we can fix this on the gnuplot end, except
> maybe by making a special case of OSX (which of course the
> autoconf tools do not want you to do).

Not a special case, but (in my understanding) a test to determine if  
we are actually dealing with libedit should be OK, right?
I'm not saying we should, I'm just trying to figure out every  
possible strategy...

/Per

Re: readline problems on OSX

[Per P. <per...@ma...>]

>>
>> However, using ./configure  --with-readline=/path/to/your/gnu/
>> libreadline should work if libreadline is installed somewhere.

This is strange, using --with-readline=/path/to/your/gnu/libreadline  
doesn't seem to affect the linking.
I still get the missing symbols error caused by libedit.

Ah, now I see! (checking configure.in):
It is supposed to be --with-readline=/usr/local for a libreadline in / 
usr/local/lib. Maybe its just me, but from ./configure --help I  
expected the option to be either:
--with-readline=/usr/local/lib
or
--with-readline=/usr/local/lib/libreadline.dylib

Maybe we should rephrase the help text a little?

/Per

Re: readline problems on OSX

[Per P. <per...@ma...>]

On Jan 25, 2007, at 22:09, Ethan Merritt wrote:

> On Thursday 25 January 2007 12:52, Per Persson wrote:
>>
>> 1) The readline issue is caused by someone at Apple having the
>> "bright" idea to symlink /usr/lib/libreadline.dylib to /usr/lib/
>> libedit.dylib
>> (The reason for not including readline are license terms, only BSD/
>> LGPL/etc. in OS X not GPL)
>>

I've put a patch (#1646558) which makes configure look for  
_remove_history rather than _readline.
This works on OS X 10.4.x, but newer versions of libedit seems to  
have that symbol, so this is likely not a future-proof test.

Let me know if you think I should commit it to CVS.

/Per

Re: readline problems on OSX

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 28 January 2007 11:36, Per Persson wrote:
> 
> On Jan 25, 2007, at 22:09, Ethan Merritt wrote:
> 
> > On Thursday 25 January 2007 12:52, Per Persson wrote:
> 
> I've put a patch (#1646558) which makes configure look for  
> _remove_history rather than _readline.
> This works on OS X 10.4.x, but newer versions of libedit seems to  
> have that symbol, so this is likely not a future-proof test.
 
I have no way to test your fix, other than to confirm that ./configure
under linux can still successfully find gnu libreadline after
applying the patch.  

> Let me know if you think I should commit it to CVS.

You'll have to make that call yourself, or ask other  OSX users for
opinions.  It sounds better than the current ./configure behaviour
on OSX.  But remember that gnuplot releases seem to stick around for
several years, so looking ahead to likely compatibility with future
OS versions is a good idea.  

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742