From: Michel P. <Mic...@en...> - 2004-01-04 10:08:18
|
on Mac OSX, using make F77=3D"g77 -lcc_dynamic" as suggested by Rafael allows a compilation with fortran without any problem. I used ./configure --disable-dyndrivers --without-pthreads to avoid other known problems. The compilation of fortran examples with make F77=3D"g77 -lcc_dynamic" in the example directory also works Michel %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Michel Peyrard, Professeur % Ph: +33 (0)4 7272 8374 % % Laboratoire de Physique % Fax: +33 (0)4 7272 8080 % % Ecole Normale Sup=E9rieure de Lyon % e-mail:Mic...@en... % % 46 all=E9e d'Italie % perso.ens-lyon.fr/michel.peyrard % % 69364 Lyon Cedex 07, France % (GPG key available on home page) % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
From: Rafael L. <rla...@us...> - 2004-01-04 10:41:23
|
* Michel Peyrard <Mic...@en...> [2004-01-04 11:08]: > on Mac OSX, using make F77="g77 -lcc_dynamic" as suggested by Rafael > allows a compilation with fortran without any problem. > > I used ./configure --disable-dyndrivers --without-pthreads to avoid other > known problems. > > The compilation of fortran examples with make F77="g77 -lcc_dynamic" in > the example directory also works I suggested the "F77=" hack to Michel as a quick way to test things. I will change configure.ac to include -lcc_dynamic automatically for the darwin ostype. Also, I will try to get the libpthread issue on MAc straightened out, following Joao's suggestions. Both fixes will go into the today's CVS release tarball. -- Rafael |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-04 12:27:13
|
On Jan 4, 2004, at 5:08 AM, Michel Peyrard wrote: > on Mac OSX, using make F77="g77 -lcc_dynamic" as suggested by Rafael > allows a compilation with fortran without any problem. > Which g77 are you using ? Did you install it with fink? thanks, - Koen. |
From: Michel P. <Mic...@en...> - 2004-01-04 14:39:21
|
> > Which g77 are you using ? Did you install it with fink? > Yes I installed it with fink. If we could work with this one, it would be better for a plplot fink package (and perhaps even necessary?) g77 --version GNU Fortran (GCC) 3.4 20031015 (experimental) Copyright (C) 2002 Free Software Foundation, Inc. Michel |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-04 15:05:59
|
On Jan 4, 2004, at 9:39 AM, Michel Peyrard wrote: >> >> Which g77 are you using ? Did you install it with fink? >> > Yes I installed it with fink. If we could work with this one, it would > be > better for a plplot fink package (and perhaps even necessary?) > Yes, that would be great. Can you explain where exactly you use the "g77 -lcc_dynamic". Do I need to modify a file? - Koen. |
From: Rafael L. <rla...@us...> - 2004-01-04 15:56:12
|
* Koen van der Drift <kvd...@ea...> [2004-01-04 10:04]: > On Jan 4, 2004, at 9:39 AM, Michel Peyrard wrote: > > >> > >>Which g77 are you using ? Did you install it with fink? > >> > >Yes I installed it with fink. If we could work with this one, it would > >be > >better for a plplot fink package (and perhaps even necessary?) > > > > Yes, that would be great. Can you explain where exactly you use the > "g77 -lcc_dynamic". Do I need to modify a file? What I suggested to Michel was a dirty hack, i.e. to launch make like this: make F77="g77 -lcc_dynamic" There is no need to change any file. If you confirm that the above is necessary to correctly compile the f77 bindings on MacOS, then I will change configure.ac to automatically add -lcc_dynamic to FLIBS when the detected host_os type is darwin*. -- Rafael |
From: Michel P. <mpe...@en...> - 2004-01-04 16:01:06
|
I confirm that make F77="g77 -lcc_dynamic" is necessary on the Mac. See my last message to Ken (a few minutes ago). It contains some details. Michel On Sun, 4 Jan 2004, Rafael Laboissiere wrote: > * Koen van der Drift <kvd...@ea...> [2004-01-04 10:04]: > > > On Jan 4, 2004, at 9:39 AM, Michel Peyrard wrote: > > > > >> > > >>Which g77 are you using ? Did you install it with fink? > > >> > > >Yes I installed it with fink. If we could work with this one, it would > > >be > > >better for a plplot fink package (and perhaps even necessary?) > > > > > > > Yes, that would be great. Can you explain where exactly you use the > > "g77 -lcc_dynamic". Do I need to modify a file? > > What I suggested to Michel was a dirty hack, i.e. to launch make like this: > > make F77="g77 -lcc_dynamic" > > There is no need to change any file. > > If you confirm that the above is necessary to correctly compile the f77 > bindings on MacOS, then I will change configure.ac to automatically add > -lcc_dynamic to FLIBS when the detected host_os type is darwin*. > > -- > Rafael > |
From: Per P. <per...@ma...> - 2004-01-04 16:38:09
|
Isn't this an issue with the g77 installed by fink, i.e. not a _generic_ problem? If it is a fink issue, it should be handled in fink's .info file. I'll try to check this against a different g77 install later tonight/tomorrow. /Per On Jan 4, 2004, at 16:51, Rafael Laboissiere wrote: > * Koen van der Drift <kvd...@ea...> [2004-01-04 10:04]: > >> On Jan 4, 2004, at 9:39 AM, Michel Peyrard wrote: >> >>>> >>>> Which g77 are you using ? Did you install it with fink? >>>> >>> Yes I installed it with fink. If we could work with this one, it >>> would >>> be >>> better for a plplot fink package (and perhaps even necessary?) >>> >> >> Yes, that would be great. Can you explain where exactly you use the >> "g77 -lcc_dynamic". Do I need to modify a file? > > What I suggested to Michel was a dirty hack, i.e. to launch make like > this: > > make F77="g77 -lcc_dynamic" > > There is no need to change any file. > > If you confirm that the above is necessary to correctly compile the f77 > bindings on MacOS, then I will change configure.ac to automatically add > -lcc_dynamic to FLIBS when the detected host_os type is darwin*. > > -- > Rafael > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for > IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys > admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-04 16:47:57
|
On Jan 4, 2004, at 11:37 AM, Per Persson wrote: > Isn't this an issue with the g77 installed by fink, i.e. not a > _generic_ problem? > If it is a fink issue, it should be handled in fink's .info file. > > I'll try to check this against a different g77 install later > tonight/tomorrow. > Per, I now have a working .info file for plplot - including f77. The only things that are missing now is support for octave and a problem with some graphic output. - Koen. |
From: Per P. <per...@ma...> - 2004-01-04 16:55:39
|
On Jan 4, 2004, at 17:46, Koen van der Drift wrote: > I now have a working .info file for plplot - including f77. The only > things that are missing now is support for octave and a problem with > some graphic output. > > - Koen. That is good news! I just wanted to make sure that bug-fixes/workarounds that are specific to fink (in this case the g77 installed by fink) doesn't make it into PLplot sources. That _will_ cause a lot of grief later... /Per |
From: Rafael L. <rla...@us...> - 2004-01-04 17:01:14
|
* Per Persson <per...@ma...> [2004-01-04 17:55]: > On Jan 4, 2004, at 17:46, Koen van der Drift wrote: > >I now have a working .info file for plplot - including f77. The only > >things that are missing now is support for octave and a problem with > >some graphic output. > > > >- Koen. > > That is good news! > > I just wanted to make sure that bug-fixes/workarounds that are specific > to fink (in this case the g77 installed by fink) doesn't make it into > PLplot sources. That _will_ cause a lot of grief later... Okay, I step back and withdraw my intention to adjust configure.ac to include the -lcc_dynamic flag. I am pleased to know that there is an easy workaround to build the Fink package. -- Rafael |
From: Michel P. <Mic...@en...> - 2004-01-04 18:44:37
|
> > > > I just wanted to make sure that bug-fixes/workarounds that are specific > > to fink (in this case the g77 installed by fink) doesn't make it into > > PLplot sources. That _will_ cause a lot of grief later... > > Okay, I step back and withdraw my intention to adjust configure.ac to > include the -lcc_dynamic flag. I am pleased to know that there is an easy > workaround to build the Fink package. I am not sure that it is a "fink" problem. It is probably a "Mac" problem and, if configure can detect the system and adjust F77 accordingly, this will help Mac users (and avoid a lot of querries on the plplot mailing list from disapointed users). As a Mac AND Linux user I hope that the next release will support both. Michel |
From: Per P. <per...@ma...> - 2004-01-04 21:28:23
|
On Jan 4, 2004, at 19:44, Michel Peyrard wrote: >>> >>> I just wanted to make sure that bug-fixes/workarounds that are >>> specific >>> to fink (in this case the g77 installed by fink) doesn't make it into >>> PLplot sources. That _will_ cause a lot of grief later... >> >> Okay, I step back and withdraw my intention to adjust configure.ac to >> include the -lcc_dynamic flag. I am pleased to know that there is an >> easy >> workaround to build the Fink package. > > I am not sure that it is a "fink" problem. It is probably a "Mac" > problem > and, if configure can detect the system and adjust F77 accordingly, > this > will help Mac users (and avoid a lot of querries on the plplot mailing > list from disapointed users). As a Mac AND Linux user I hope that the > next > release will support both. The ultimate cause of the fortran mess on OS X is Apple's decision _not_ to supply g77 as part of their GCC toolchain. This means that people get e.g. g77 from different places such as fink, DarwinPorts or from some site supplying a binary installer. Some g77 have been built from FSF sources, some from Apple's darwin repository (which is a fork of FSF), some are based on the 3.3 sources whereas some are 3.4 based and yet others are based on a random day snapshot. All in all, it is very hard to deal with g77 on OS X. So, I do agree, it is not a fink problem, it is a Mac OS X problem. But, since only fink knows the exact details of the g77 supplied by fink, that is where the kludgery should go, not into the sources of PLplot and other projects. IMHO, not supplying g77 as part of their toolchain is a bug in OS X and should be filed as such with Apple. The more bugreports they get, the more likely the situation will change. Sorry for a somewhat OT mailing... /Per > > Michel > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for > IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys > admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Alan W. I. <ai...@us...> - 2004-01-04 22:30:50
|
On 2004-01-04 22:28+0100 Per Persson wrote: > The ultimate cause of the fortran mess on OS X is Apple's decision > _not_ to supply g77 as part of their GCC toolchain. > This means that people get e.g. g77 from different places such as fink, > DarwinPorts or from some site supplying a binary installer. > Some g77 have been built from FSF sources, some from Apple's darwin > repository (which is a fork of FSF), some are based on the 3.3 sources > whereas some are 3.4 based and yet others are based on a random day > snapshot. > All in all, it is very hard to deal with g77 on OS X. > > So, I do agree, it is not a fink problem, it is a Mac OS X problem. > But, since only fink knows the exact details of the g77 supplied by > fink, that is where the kludgery should go, not into the sources of > PLplot and other projects. > > IMHO, not supplying g77 as part of their toolchain is a bug in OS X and > should be filed as such with Apple. The more bugreports they get, the > more likely the situation will change. > > Sorry for a somewhat OT mailing... No problem, somewhat OT makes a nice break to the day. From an outsider's perspective, I am just amazed that fink doesn't have its own independent gcc tool chain with a self-consistent g77, g++, gcj, gcc, etc. The way it works (if nothing is changed from the old days when I used to build the gcc tool chain all the time) is you must build the gcc component plus any add-ons such as g77, g++, and gcj. Essentially the guy who is building the g77 fink package must throw away the consistent gcc part before he packages the g77 subset of his results. That seems really bizarre (again from my outside perspective). Without their own independent gcc tool chain, fink developers have to go cap-in-hand to Apple to, e.g., ask them to restore a consistent g77. But Apple may not wish to do that because of some marketing decision (like pushing somebody elses fortran compiler that costs big bucks.) If they package an independent fink gcc tool chain, fink developers have just made themselves a whole lot more independent of any marketing decisions or foolishness that Apple wants to get up to. Is there some fundamental reason why fink leadership has decided not to encourage an independent gcc tool chain? Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Per P. <per...@ma...> - 2004-01-04 23:00:35
|
On Jan 4, 2004, at 23:30, Alan W. Irwin wrote: > On 2004-01-04 22:28+0100 Per Persson wrote: > >> >> IMHO, not supplying g77 as part of their toolchain is a bug in OS X >> and >> should be filed as such with Apple. The more bugreports they get, the >> more likely the situation will change. >> >> Sorry for a somewhat OT mailing... > > No problem, somewhat OT makes a nice break to the day. > > From an outsider's perspective, I am just amazed that fink doesn't > have its > own independent gcc tool chain with a self-consistent g77, g++, gcj, > gcc, > etc. The way it works (if nothing is changed from the old days when I > used > to build the gcc tool chain all the time) is you must build the gcc > component plus any add-ons such as g77, g++, and gcj. Essentially the > guy > who is building the g77 fink package must throw away the consistent > gcc part > before he packages the g77 subset of his results. That seems really > bizarre > (again from my outside perspective). > > Without their own independent gcc tool chain, fink developers have to > go > cap-in-hand to Apple to, e.g., ask them to restore a consistent g77. > But > Apple may not wish to do that because of some marketing decision (like > pushing somebody elses fortran compiler that costs big bucks.) > > If they package an independent fink gcc tool chain, fink developers > have > just made themselves a whole lot more independent of any marketing > decisions > or foolishness that Apple wants to get up to. Is there some > fundamental > reason why fink leadership has decided not to encourage an independent > gcc > tool chain? I can't speak for fink, so this is purely my own opinions/speculations: Apple inherited a forked, heavily modified gcc toolchain from NeXT. There are a lot of stuff necessary to build OS X itself and apps for it in that toolchain. Hence, the FSF toolchain is not sufficient on OS X, yet. The engineers at Apple is actively contributing those mods back to the FSF sources, just have a look at any gcc mailing list. Personally, I don't believe that the removal of g77 was to protect the market share of IBM (xlf), NAG or Absoft. My guess wrt g77 is that they made a decision, based on their then current customer profile, that they simply didn't have the manpower to commit to test/develop/supply g77 in addition to C/ObjC and C++ (the latter was badly broken in some respects). Then, suddenly, OS X was a smash hit among a lot of scientist and that decision turned out to be a _really_ bad one. So far, they have set up a mailing list for fortran users, and maybe if enough people bug them about g77, it will become a standard part of their tools. /Per |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-04 16:43:32
|
On Jan 4, 2004, at 10:51 AM, Rafael Laboissiere wrote: > What I suggested to Michel was a dirty hack, i.e. to launch make like > this: > > make F77="g77 -lcc_dynamic" > > There is no need to change any file. > > If you confirm that the above is necessary to correctly compile the f77 > bindings on MacOS, then I will change configure.ac to automatically add > -lcc_dynamic to FLIBS when the detected host_os type is darwin*. > Yes it works. For the fink package I had to pass F77=g77 -lcc_dynamic (without the quotes!) to MAKEFLAGS to get it to work. And, it now works with --dyndrivers-enabled! Any way I can test that part? - Koen. |
From: Rafael L. <rla...@us...> - 2004-01-04 16:58:10
|
* Koen van der Drift <kvd...@ea...> [2004-01-04 11:42]: > Yes it works. For the fink package I had to pass F77=g77 -lcc_dynamic > (without the quotes!) to MAKEFLAGS to get it to work. And, it now works > with --dyndrivers-enabled! Great! Could you please send to me the config.log file and the resulting build.log obtained by: make 2>&1 > ../build.log when you configure with --enable-dyndrivers? Michel Peyrard have had problems with get-drv-info when dyndrivers are enabled and if you are finally succeeding that, then it is good news. > Any way I can test that part? Which part do you mean? If you mean the dyndrivers part, then compile the x01c example and run it with any of the driver modules present in the <prefix>lib/plplot<version>/driversd/ directory. -- Rafael |
From: Rafael L. <rla...@us...> - 2004-01-04 18:40:02
|
* Rafael Laboissiere <rla...@us...> [2004-01-04 17:53]: > * Koen van der Drift <kvd...@ea...> [2004-01-04 11:42]: > > > Yes it works. For the fink package I had to pass F77=g77 -lcc_dynamic > > (without the quotes!) to MAKEFLAGS to get it to work. And, it now works > > with --dyndrivers-enabled! > > Great! Could you please send to me the config.log file and the resulting > build.log obtained by: > > make 2>&1 > ../build.log Thanks for sending the build.log privately to me. I am very pleased to see the following lines in that file: gcc -g -O2 -o get-drv-info get_drv_info-get-drv-info.o ../libltdl/.libs/libltdlc.a -ldl ./get-drv-info `echo dg300.la | sed 's/.la//'` > dg300.rc ./get-drv-info `echo hpgl.la | sed 's/.la//'` > hpgl.rc ./get-drv-info `echo impress.la | sed 's/.la//'` > impress.rc ./get-drv-info `echo ljii.la | sed 's/.la//'` > ljii.rc ./get-drv-info `echo ljiip.la | sed 's/.la//'` > ljiip.rc ./get-drv-info `echo mem.la | sed 's/.la//'` > mem.rc ./get-drv-info `echo ntk.la | sed 's/.la//'` > ntk.rc ./get-drv-info `echo null.la | sed 's/.la//'` > null.rc ./get-drv-info `echo pbm.la | sed 's/.la//'` > pbm.rc ./get-drv-info `echo plmeta.la | sed 's/.la//'` > plmeta.rc ./get-drv-info `echo ps.la | sed 's/.la//'` > ps.rc ./get-drv-info `echo pstex.la | sed 's/.la//'` > pstex.rc ./get-drv-info `echo tek.la | sed 's/.la//'` > tek.rc ./get-drv-info `echo tk.la | sed 's/.la//'` > tk.rc ./get-drv-info `echo xfig.la | sed 's/.la//'` > xfig.rc ./get-drv-info `echo xwin.la | sed 's/.la//'` > xwin.rc This means that dyndrivers is finally a reality in the MacOS system! Could you please get in touch with Michel Peyrard and check how your system differs from his? Running get-drv-info fails for him in a very strange way. I suspect there may be some problem with libdl in his system (file /lib/libdl.so in Linux, dunno where it is on MacOS) -- Rafael |
From: Michel P. <Mic...@en...> - 2004-01-04 18:37:57
|
Koen, Thanks on behalf of the Mac users! This fink package, when it is available, will make their life easier (and should help to extend the use of plplot). I don't know how you got dyndrivers to work since it systematically fails for me, when I compile the tarball. Michel |
From: Michel P. <mpe...@en...> - 2004-01-04 15:57:29
|
> > Yes, that would be great. Can you explain where exactly you use the > "g77 -lcc_dynamic". Do I need to modify a file? > It is necessary to compile a graphic fortran program (also true if I compile pgplot). Otherwise load stops with undefined restFP undefined saveFP Here is the error message: ---- g77 -dynamiclib -single_module -o .libs/libplplotf77d.9.0.0.dylib .libs/sc3d.o .libs/sccont.o .libs/scstubs.o .libs/strutil.o .libs/sfstubs.o -L/usr/X11R6/lib /usr/local/src/plplot-5.2.1.cvs.20031231/lib/csa/.libs/libcsirocsa.dylib ../../src/.libs/libplplotd.dylib -install_name /usr/local/plotcvs/lib/libplplotf77d.9.dylib -compatibility_version 10 -current_version 10.0 ld: warning -dylib_install_name /usr/local/plotcvs/lib/libplplotf77d.9.dylib not found in segment address table LD_SEG_ADDR_TABLE /sw/var/lib/fink/prebound/seg_addr_table ld: warning prebinding disabled because of undefined symbols ld: Undefined symbols: restFP saveFP /usr/bin/libtool: internal link edit command failed make[3]: *** [libplplotf77d.la] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 --- I made a search of restFP on the web and found that it is a well known problem on the Mac. The solution proposed was to link with -lgcc -lcc_dynamic It seems that the -lcc_dynamic is sufficient. It is probably not a perfect solution because when I compile a fortran program with make x01f I get a long list of warnings such as: /usr/bin/ld: warning prebinding not disabled because (__TEXT segment (address = 0x0 size = 0x5000) of /usr/local/plotcvs31b/lib/libcsirocsa.0.dylib overlaps with __TEXT segment (address = 0x0 size = 0x45000) of /usr/local/plotcvs31b/lib/libplplotd.9.dylib /usr/bin/ld: warning prebinding not disabled because (__DATA segment (address = 0x5000 size = 0x1000) of /usr/local/plotcvs31b/lib/libcsirocsa.0.dylib overlaps with __TEXT segment (address = 0x0 size = 0x45000) of /usr/local/plotcvs31b/lib/libplplotd.9.dylib /usr/bin/ld: warning prebinding not disabled because (__LINKEDIT segment (address = 0x6000 size = 0x9000) of /usr/local/plotcvs31b/lib/libcsirocsa.0.dylib overlaps with __TEXT segment (address = 0x0 size = 0x45000) of /usr/local/plotcvs31b/lib/libplplotd.9.dylib creating x01f Probably some other libraries should not be used. I think that some tests done previoulsy showed that I did not need crt2.o In spite of these warnings compilation goes through. I noticed that make F77="g77 -lcc_dynamic" is essential when I compile the plplot library. After that g77 -O3 -Wunused -Wuninitialized -fno-backslash -o x01f x01f.f -I/usr/local/plotcvs31b/include/plplot -L/usr/local/plotcvs31b/lib -L/usr/X11R6/lib/ -lX11 -lplplotf77d -lplplotd does compile the program x01f (with many warnings) (does that mean that restFP saveFP are now known through the plplot libraries?) Michel |