I have uploaded the source for Poly/ML 5.5.1 to the SourceForge site so it is now officially released. I still need to create installers for Windows. The release notes at http://www.polyml.org/docs/ReleaseNotes.html give a general overview of the changes over the last year. There have been no big changes which is the reason it's 5.5.1 rather than 5.6.
David
That's great :) Has the -fixes branch also been updated - or will it be?
On Tue, Sep 17, 2013 at 5:57 PM, David Matthews < David.Matthews at prolingua.co.uk> wrote:
I have uploaded the source for Poly/ML 5.5.1 to the SourceForge site so it is now officially released. I still need to create installers for Windows. The release notes at http://www.polyml.org/docs/**ReleaseNotes.htmlhttp://www.polyml.org/docs/ReleaseNotes.htmlgive a general overview of the changes over the last year. There have been no big changes which is the reason it's 5.5.1 rather than 5.6.
David ______________________________**_________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/**mailman/listinfo/polymlhttp://lists.inf.ed.ac.uk/mailman/listinfo/polyml
On 17/09/2013 18:35, Ramana Kumar wrote:
That's great :) Has the -fixes branch also been updated - or will it be?
I've created a 5.5.1-fixes branch in the root. See http://sourceforge.net/p/polyml/code/HEAD/tree/ At the moment it is just a branch of the current SVN.
David
Thanks for the pointer.
I would like to report that the new default to not build a shared library means Poly/ML 5.5.1 does not build HOL4 unless you use the --enable-shared option at configure time. Is this as expected, or is there some other possible solution?
Interestingly, even when --enable-shared is given at configure time, the polyc script prints some errors where it probably shouldn't: % polyc Usage: file [-bchikLlNnprsvz0] [--apple] [--mime-encoding] [--mime-type] [-e testname] [-F separator] [-f namefile] [-m magicfiles] file ... file -C [-m magicfiles] file [--help] /usr/lib/libpolymain.a(polystub.o): In function `main': (.text.startup+0x1): undefined reference to `poly_exports' collect2: error: ld returned 1 exit status
And here is the beginning of the long list of errors, if --enable-shared is not used when building poly, and then trying to build hol:
~/HOL % poly < tools/smart-configure.sml Poly/ML 5.5.1 Release
HOL smart configuration.
Determining configuration parameters: holdir OS poly polymllibdir OS: linux poly: /usr/bin/poly polymllibdir: /usr/lib holdir: /home/ramana/HOL DOT_PATH: /usr/bin/dot
Configuration will begin with above values. If they are wrong press Control-C.
Will continue in 1 seconds.
Loading system specific functions Compiling system specific functions (sig sml) Beginning configuration. Making tools/mllex/mllex.exe. Poly/ML 5.5.1 Release /usr/lib/libpolyml.a(basicio.o): In function `retry_rts_call(TaskData*)': (.text+0x51f): undefined reference to `__cxa_allocate_exception' /usr/lib/libpolyml.a(basicio.o): In function `retry_rts_call(TaskData*)': (.text+0x534): undefined reference to `__cxa_throw' /usr/lib/libpolyml.a(basicio.o): In function `BasicIO::~BasicIO()': (.text._ZN7BasicIOD0Ev[_ZN7BasicIOD0Ev]+0x8): undefined reference to `operator delete(void*)' /usr/lib/libpolyml.a(basicio.o): In function `WaitStream::~WaitStream()': (.text._ZN10WaitStreamD0Ev[_ZN10WaitStreamD0Ev]+0x8): undefined reference to `operator delete(void*)' /usr/lib/libpolyml.a(basicio.o):(.rodata._ZTI10WaitStream[_ZTI10WaitStream]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info' /usr/lib/libpolyml.a(basicio.o):(.rodata._ZTI7BasicIO[_ZTI7BasicIO]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info' /usr/lib/libpolyml.a(processes.o): In function `Processes::TestSynchronousRequests(TaskData*)': (.text+0x1de): undefined reference to `__cxa_allocate_exception' /usr/lib/libpolyml.a(processes.o): In function `Processes::TestSynchronousRequests(TaskData*)': (.text+0x1ed): undefined reference to `__cxa_throw' /usr/lib/libpolyml.a(processes.o): In function `Processes::TestSynchronousRequests(TaskData*)': (.text+0x229): undefined reference to `__cxa_allocate_exception' /usr/lib/libpolyml.a(processes.o): In function `Processes::TestSynchronousRequests(TaskData*)': (.text+0x23e): undefined reference to `__cxa_throw' /usr/lib/libpolyml.a(processes.o): In function `Processes::BlockAndRestart(TaskData*, Waiter*, bool, int)': (.text+0x3ac): undefined reference to `__cxa_allocate_exception' /usr/lib/libpolyml.a(processes.o): In function `Processes::BlockAndRestart(TaskData*, Waiter*, bool, int)': (.text+0x3c1): undefined reference to `__cxa_throw' /usr/lib/libpolyml.a(processes.o): In function `Processes::Exit(int)': (.text+0x58c): undefined reference to `pthread_create' /usr/lib/libpolyml.a(processes.o): In function `Processes::Init()': (.text+0x5ee): undefined reference to `pthread_key_create' /usr/lib/libpolyml.a(processes.o): In function `Processes::Stop()': (.text+0x748): undefined reference to `pthread_key_delete' /usr/lib/libpolyml.a(processes.o): In function `Processes::TestAnyEvents(TaskData*)': (.text+0x7cf): undefined reference to `__cxa_allocate_exception' /usr/lib/libpolyml.a(processes.o): In function `Processes::TestAnyEvents(TaskData*)': (.text+0x7e4): undefined reference to `__cxa_throw' /usr/lib/libpolyml.a(processes.o): In function `Processes::CreateNewTaskData(SaveVecEntry*, SaveVecEntry*, SaveVecEntry*, PolyWord)': (.text+0xbc6): undefined reference to `operator new(unsigned long)' /usr/lib/libpolyml.a(processes.o): In function `Processes::CreateNewTaskData(SaveVecEntry*, SaveVecEntry*, SaveVecEntry*, PolyWord)': (.text+0xcd1): undefined reference to `pthread_setspecific' /usr/lib/libpolyml.a(processes.o): In function `Processes::CreateNewTaskData(SaveVecEntry*, SaveVecEntry*, SaveVecEntry*, PolyWord)': (.text+0xd7b): undefined reference to `__cxa_allocate_exception' /usr/lib/libpolyml.a(processes.o): In function `Processes::CreateNewTaskData(SaveVecEntry*, SaveVecEntry*, SaveVecEntry*, PolyWord)': (.text+0xd8a): undefined reference to `__cxa_throw' /usr/lib/libpolyml.a(processes.o): In function `Processes::CreateNewTaskData(SaveVecEntry*, SaveVecEntry*, SaveVecEntry*, PolyWord)': (.text+0xdb9): undefined reference to `operator delete(void*)' /usr/lib/libpolyml.a(processes.o): In function `Processes::CreateNewTaskData(SaveVecEntry*, SaveVecEntry*, SaveVecEntry*, PolyWord)': (.text+0xdd4): undefined reference to `__cxa_allocate_exception' /usr/lib/libpolyml.a(processes.o): In function `Processes::CreateNewTaskData(SaveVecEntry*, SaveVecEntry*, SaveVecEntry*, PolyWord)': (.text+0xde3): undefined reference to `__cxa_throw' /usr/lib/libpolyml.a(processes.o): In function `Processes::ThreadExit(TaskData*)': (.text+0xf98): undefined reference to `pthread_sigmask' /usr/lib/libpolyml.a(processes.o): In function `Processes::ThreadExit(TaskData*)': (.text+0xfa2): undefined reference to `pthread_setspecific' /usr/lib/libpolyml.a(processes.o): In function `NewThreadFunction(void*)': (.text+0x1068): undefined reference to `pthread_setspecific' /usr/lib/libpolyml.a(processes.o): In function `NewThreadFunction(void*)': (.text+0x10b3): undefined reference to `__cxa_get_exception_ptr' /usr/lib/libpolyml.a(processes.o): In function `NewThreadFunction(void*)': (.text+0x10bb): undefined reference to `__cxa_begin_catch' /usr/lib/libpolyml.a(processes.o): In function `NewThreadFunction(void*)': (.text+0x10d0): undefined reference to `__cxa_end_catch' /usr/lib/libpolyml.a(processes.o): In function `Processes::BeginRootThread(PolyObject*)': (.text+0x1135): undefined reference to `operator new(unsigned long)' /usr/lib/libpolyml.a(processes.o): In function `Processes::BeginRootThread(PolyObject*)': (.text+0x124c): undefined reference to `pthread_create' /usr/lib/libpolyml.a(processes.o): In function `Processes::BeginRootThread(PolyObject*)': (.text+0x158c): undefined reference to `__cxa_get_exception_ptr' /usr/lib/libpolyml.a(processes.o): In function `Processes::BeginRootThread(PolyObject*)': (.text+0x1598): undefined reference to `vtable for std::bad_alloc' /usr/lib/libpolyml.a(processes.o): In function `Processes::BeginRootThread(PolyObject*)': (.text+0x159d): undefined reference to `__cxa_begin_catch' /usr/lib/libpolyml.a(processes.o): In function `Processes::BeginRootThread(PolyObject*)': (.text+0x15c1): undefined reference to `operator delete(void*)' /usr/lib/libpolyml.a(processes.o): In function `Processes::BeginRootThread(PolyObject*)': (.text+0x15d3): undefined reference to `std::bad_alloc::~bad_alloc()' /usr/lib/libpolyml.a(processes.o): In function `Processes::BeginRootThread(PolyObject*)': (.text+0x15d8): undefined reference to `__cxa_end_catch'
On Tue, Sep 17, 2013 at 6:44 PM, David Matthews < David.Matthews at prolingua.co.uk> wrote:
On 17/09/2013 18:35, Ramana Kumar wrote:
That's great :) Has the -fixes branch also been updated - or will it be?
I've created a 5.5.1-fixes branch in the root. See http://sourceforge.net/p/**polyml/code/HEAD/tree/http://sourceforge.net/p/polyml/code/HEAD/tree/ At the moment it is just a branch of the current SVN.
David
On 17/09/2013 19:43, Ramana Kumar wrote:
I would like to report that the new default to not build a shared library means Poly/ML 5.5.1 does not build HOL4 unless you use the --enable-shared option at configure time. Is this as expected, or is there some other possible solution?
This issue with HOL4 did come up during testing. It seems that when libpolyml is built with --disable-shared it is necessary to give more libraries on the linking line than when it is built with --enable-shared. If the libraries are missing then you get the errors with missing symbols.
The complication is that exactly which libraries have to be included depend on how libpolyml was built. The configure script detects the libraries that are needed to build "poly" and builds a linker command line from that. In particular, -lgmp is included only if GMP is present. This all makes it difficult for a build script such as that used by HOL4 to have a standard linker command line.
The idea of "polyc" is to capture the linker command line that was used to build "poly" on the particular platform and make it available for other applications. So, I would recommend that HOL4 and other applications check for the presence of "polyc" and use that to do the linking if it is available.
By changing to --disable-shared as the default, I felt that this would simplify the process of running applications, particularly "poly", at the expense of making linking a bit more difficult. Those packaging Poly/ML for particular distributions may want to use --enable-shared but they will be installing libpolyml to a "standard" location where the loader can find it.
Interestingly, even when --enable-shared is given at configure time, the polyc script prints some errors where it probably shouldn't: % polyc Usage: file [-bchikLlNnprsvz0] [--apple] [--mime-encoding] [--mime-type] [-e testname] [-F separator] [-f namefile] [-m magicfiles] file ... file -C [-m magicfiles] file [--help] /usr/lib/libpolymain.a(polystub.o): In function `main': (.text.startup+0x1): undefined reference to `poly_exports' collect2: error: ld returned 1 exit status
OK, I hadn't tested "polyc" without any arguments. That's a bug. It ought to behave the same as polyc --help It is always supposed to be provided with a source or object file name.
David
On Wed, Sep 18, 2013 at 12:51 PM, David Matthews < David.Matthews at prolingua.co.uk> wrote:
On 17/09/2013 19:43, Ramana Kumar wrote:
I would like to report that the new default to not build a shared library means Poly/ML 5.5.1 does not build HOL4 unless you use the --enable-shared option at configure time. Is this as expected, or is there some other possible solution?
This issue with HOL4 did come up during testing. It seems that when libpolyml is built with --disable-shared it is necessary to give more libraries on the linking line than when it is built with --enable-shared. If the libraries are missing then you get the errors with missing symbols.
The complication is that exactly which libraries have to be included depend on how libpolyml was built. The configure script detects the libraries that are needed to build "poly" and builds a linker command line from that. In particular, -lgmp is included only if GMP is present. This all makes it difficult for a build script such as that used by HOL4 to have a standard linker command line.
The idea of "polyc" is to capture the linker command line that was used to build "poly" on the particular platform and make it available for other applications. So, I would recommend that HOL4 and other applications check for the presence of "polyc" and use that to do the linking if it is available.
Do you happen to know whether and how polyc could be used to build HOL4 when poly was built with --disabled-shared? I think I tried using polyc < tools/smart-configure.sml to start the HOL4 build process (i.e. using polyc instead of poly), but it didn't work. (I should try it again to be sure.) But would you expect to have to change the contents of smart-configure.sml to make this work?
By changing to --disable-shared as the default, I felt that this would simplify the process of running applications, particularly "poly", at the expense of making linking a bit more difficult. Those packaging Poly/ML for particular distributions may want to use --enable-shared but they will be installing libpolyml to a "standard" location where the loader can find it.
Interestingly, even when --enable-shared is given at configure time, the
polyc script prints some errors where it probably shouldn't: % polyc Usage: file [-bchikLlNnprsvz0] [--apple] [--mime-encoding] [--mime-type] [-e testname] [-F separator] [-f namefile] [-m magicfiles] file ... file -C [-m magicfiles] file [--help] /usr/lib/libpolymain.a(**polystub.o): In function `main': (.text.startup+0x1): undefined reference to `poly_exports' collect2: error: ld returned 1 exit status
OK, I hadn't tested "polyc" without any arguments. That's a bug. It ought to behave the same as polyc --help It is always supposed to be provided with a source or object file name.
David
On 18/09/2013 18:21, Ramana Kumar wrote:
Do you happen to know whether and how polyc could be used to build HOL4 when poly was built with --disabled-shared? I think I tried using polyc < tools/smart-configure.sml to start the HOL4 build process (i.e. using polyc instead of poly), but it didn't work. (I should try it again to be sure.) But would you expect to have to change the contents of smart-configure.sml to make this work?
You can't use polyc < tools/smart-configure.sml. You will need to use "poly" here. You need to look more carefully at what smart-configure actually does. Somewhere in there it will either write out a script to link the object file or it will create a script which uses one of a number of pre-built scripts. All this is very specific to the HOL4 build process.
David
18/09/13 12:51, David Matthews wrote:
The complication is that exactly which libraries have to be included depend on how libpolyml was built. The configure script detects the libraries that are needed to build "poly" and builds a linker command line from that. In particular, -lgmp is included only if GMP is present. This all makes it difficult for a build script such as that used by HOL4 to have a standard linker command line.
The idea of "polyc" is to capture the linker command line that was used to build "poly" on the particular platform and make it available for other applications. ...
One well-established aid for constructing suitable command-line options is pkg-config. This may be more useful for use in Makefiles due to greater flexibility than polyc. For pkg-config, a library installs a PC file. (There are quite a few examples in /usr/lib64/pkgconfig/ on my system.) This tells pkg-config which command line options are required for building with that library.
A while ago, I experimented with this, creating the attached PC file for polyml and adapting a Makefile to use pkg-config to construct the polyml linker command-line options. This seems to work. For example, the Makefile rule (for Poly/ML built with --enable-shared)
$(NAME)-polyml : $(NAME)-polyml.o $(CC) -o $@ -L$(POLYMLLIB) -lpolymain -lpolyml $<
was changed to
$(CC) -o $@ `pkg-config --libs polyml` $<
given the attached polyml.pc in the pkg-config path. For static linking, this would be
$(CC) -o $@ -static `pkg-config --libs --static polyml` $<
however this requires all dependencies to be static: given that pkg-config generates command-line options for all dependencies, it is not possible to switch back and forth between -static and -dynamic.
For Poly/ML built with --disable-shared (now default) the same commands also work by using a slightly different polyml.pc where certain dependencies are moved from Libs.private to Libs as they are always required for linking. This is shown in polyml.pc-disable-shared, also attached.
With pkg-config, other variables can be extracted too. For example, the Makefile lines
POLYML := $(shell which poly 2> /dev/null) POLYMLBIN := $(patsubst %/,%,$(dir $(POLYML))) POLYMLHOME := $(patsubst %/,%,$(dir $(POLYMLBIN))) POLYMLLIB := $(POLYMLHOME)/lib
were replaced by
POLYMLBIN := `pkg-config --variable=bindir polyml` POLYMLLIB := `pkg-config --variable=libdir polyml` POLYML := $(POLYMLBIN)/poly POLYMLROOT := `pkg-config --variable=prefix polyml`
Furthermore, should any future enhancements to the FFI want to allow C-side code to reference symbols from Poly/ML H files, pkg-config can produce command-line options for C include directories too. I seem to recall that I once wanted to include a MLton H file in code on the C-side of the MLton FFI.
There is a default pkg-config path which can be overridden with the environment variable PKG_CONFIG_PATH. That seems as good a way as any to indicate which version of Poly/ML should be used when building an application.
Regards, Phil
On 19/09/2013 07:44, Phil Clayton wrote:
18/09/13 12:51, David Matthews wrote:
The complication is that exactly which libraries have to be included depend on how libpolyml was built. The configure script detects the libraries that are needed to build "poly" and builds a linker command line from that. In particular, -lgmp is included only if GMP is present. This all makes it difficult for a build script such as that used by HOL4 to have a standard linker command line.
The idea of "polyc" is to capture the linker command line that was used to build "poly" on the particular platform and make it available for other applications. ...
One well-established aid for constructing suitable command-line options is pkg-config. This may be more useful for use in Makefiles due to greater flexibility than polyc. For pkg-config, a library installs a PC file. (There are quite a few examples in /usr/lib64/pkgconfig/ on my system.) This tells pkg-config which command line options are required for building with that library.
Thanks for the suggestion. It certainly seems like a good idea to install pkg-config files if possible. It does look as though they would have to be generated by a script in the same way as polyc is built by buildpolyc since the libraries would depend on what configure has found.
I don't know how useful it will be in general, though. I've done a quick look and pkg-config doesn't seem to be installed on several set-ups I looked at including Mac OS X and Solaris. The other problem is that it is going to require the PC files to be written into /usr/lib/pkgconfig or some other non-user-writable directory. One of the problems I was trying to work round was the fact that many users of Poly/ML are running on systems that are managed centrally and they don't have root access. It's this that makes shared libraries a problem because libpolyml can't be installed to /usr/lib or /usr/local/lib. All this means that anyone distributing code, such as HOL4 or Metit that are intended to be built with poly, can't rely on pkg-config.
David
On 19/09/13 15:14, David Matthews wrote:
I don't know how useful it will be in general, though. I've done a quick look and pkg-config doesn't seem to be installed on several set-ups I looked at including Mac OS X and Solaris. The other problem is that it is going to require the PC files to be written into /usr/lib/pkgconfig or some other non-user-writable directory. One of the problems I was trying to work round was the fact that many users of Poly/ML are running on systems that are managed centrally and they don't have root access. It's this that makes shared libraries a problem because libpolyml can't be installed to /usr/lib or /usr/local/lib. All this means that anyone distributing code, such as HOL4 or Metit that are intended to be built with poly, can't rely on pkg-config.
It should just be installed to $PREFIX/lib/pkgconfig; users can then export the environment variable PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH before building the tool that uses Poly/ML, in much the same way that they have to set PATH=$PREFIX/bin:$PATH (or supply an absolute path to poly). pkg-config will then find the .pc file.
pkg-config is mostly a Linux thing (although I suspect it's easily found on *BSD systems), so it's not so useful for Windows or the proprietary unices like OS X and Solaris.
Alex
On 9/19/13 4:47 PM, Alex Merry wrote:
On 19/09/13 15:14, David Matthews wrote:
I don't know how useful it will be in general, though. I've done a quick look and pkg-config doesn't seem to be installed on several set-ups I looked at including Mac OS X and Solaris. The other problem is that it is going to require the PC files to be written into /usr/lib/pkgconfig or some other non-user-writable directory. One of the problems I was trying to work round was the fact that many users of Poly/ML are running on systems that are managed centrally and they don't have root access. It's this that makes shared libraries a problem because libpolyml can't be installed to /usr/lib or /usr/local/lib. All this means that anyone distributing code, such as HOL4 or Metit that are intended to be built with poly, can't rely on pkg-config.
It should just be installed to $PREFIX/lib/pkgconfig; users can then export the environment variable PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH before building the tool that uses Poly/ML, in much the same way that they have to set PATH=$PREFIX/bin:$PATH (or supply an absolute path to poly). pkg-config will then find the .pc file.
pkg-config is mostly a Linux thing (although I suspect it's easily found on *BSD systems), so it's not so useful for Windows or the proprietary unices like OS X and Solaris.
A possible option would also be to generate a shell script, say poly-config, and install on the same path as poly which would accept the same options as pkg-config. The script could be generated in case the pkg-config is not available. This would solve the portability issue for non linux systems.
Alex _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
Ramunas
19/09/13 16:05, Ram?nas Gutkovas wrote:
On 9/19/13 4:47 PM, Alex Merry wrote:
On 19/09/13 15:14, David Matthews wrote:
I don't know how useful it will be in general, though. I've done a quick look and pkg-config doesn't seem to be installed on several set-ups I looked at including Mac OS X and Solaris.
I didn't really have a feel for its general prevalence outside the Linux world and agree that it may not be useful for all applications. A quick search suggests it should be straightforward to build though, e.g. https://github.com/LearnBoost/node-canvas/wiki/Installation---OSX (though --with-internal-glib may be needed if glib is not present). Possibly even a single-command install, e.g. http://cduu.wordpress.com/2011/11/26/install-pkg-config-on-mac-os-x/ However, I doubt applications such as HOL4 would want to force this on those building them.
The other problem is that it is going to require the PC files to be written into /usr/lib/pkgconfig or some other non-user-writable directory. One of the problems I was trying to work round was the fact that many users of Poly/ML are running on systems that are managed centrally and they don't have root access. It's this that makes shared libraries a problem because libpolyml can't be installed to /usr/lib or /usr/local/lib. All this means that anyone distributing code, such as HOL4 or Metit that are intended to be built with poly, can't rely on pkg-config.
It should just be installed to $PREFIX/lib/pkgconfig; users can then export the environment variable PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH before building the tool that uses Poly/ML, in much the same way that they have to set PATH=$PREFIX/bin:$PATH (or supply an absolute path to poly). pkg-config will then find the .pc file.
Yes, and more generally, once a build system has determined the location of poly it could set PKG_CONFIG_PATH within the build process.
Possibly $PREFIX/share/pkgconfig would be better installation location. One would want the property that when $PREFIX is /usr, the PC file is located in the default pkg-config path. This is $libdir/pkgconfig:$datadir/pkgconfig where libdir and datadir are determined by the installation location of pkg-config. pkg-config can report these:
[pclayton at rizzo ~]$ pkg-config --variable=pc_path pkg-config /usr/lib64/pkgconfig:/usr/share/pkgconfig
libdir is either .../lib or .../lib64 depending on the platform so datadir, which is .../share, avoids the difference.
On 9/19/13 4:47 PM, Alex Merry wrote:
pkg-config is mostly a Linux thing (although I suspect it's easily found on *BSD systems), so it's not so useful for Windows or the proprietary unices like OS X and Solaris.
pkg-config seems to have support for these platforms (mingw in the case of Windows). It would be useful to know how readily available it is via a package management system on those platforms.
19/09/13 16:05, Ram?nas Gutkovas wrote:
A possible option would also be to generate a shell script, say poly-config, and install on the same path as poly which would accept the same options as pkg-config. The script could be generated in case the pkg-config is not available. This would solve the portability issue for non linux systems.
Yes, or even a subset of the behaviour.
Standing back, there appear to be (at least) two levels here: 1. Indicating to a build system whether Poly/ML SO files are available so it can select suitable linker flags 2. Providing the required linker flags for any Poly/ML installation The first would suffice but the second would be nice.
Regards, Phil
Overall, my feeling is that it would be a good idea to create the PC file as part of the build process but it's not going to be a substitute for "polyc". "polyc" was originally intended as a convenient way to compile and link programs written in ML for users who are more familiar with the compile-and-link model of languages like C than the read-eval-print loop of "poly". It can also be used for the linking step alone.
I would assume that there are autoconf macros available to automate some of the process of creating and installing PC files. If there are then that would be the way to go. There seem to be quite a few packages that already create PC files if the list on my Debian machine is anything to go by. I'll have a look at their autoconf scripts.
I'm not so keen on trying to reproduce the functionality of pkg-config with a poly-config script. It's probably better to encourage users who want to go down that route to install pkg-config directly.
There seem to be a number of applications around that are built around linking object files exported with PolyML.export. I want to try and find convenient and portable ways to do the linking process.
David
Phil, I've just committed support for pkg-config with Poly/ML. Would you like to have a look at it and see if it works as you expect? Let me know if there are any changes needed. You had separate versions for the shared and static libraries. I can see why you did that but it looks like it would be a lot more work.
Regards, David
David,
26/09/13 18:31, David Matthews wrote:
I've just committed support for pkg-config with Poly/ML. Would you like to have a look at it and see if it works as you expect? Let me know if there are any changes needed. You had separate versions for the shared and static libraries. I can see why you did that but it looks like it would be a lot more work.
Thanks for the update. The polyml.pc file appears to be generated as expected. Using one set of linking flags for shared and static libraries does not appear to matter actually: although unnecessary linker flags can create unnecessary library dependencies, ldd shows that there isn't any additional dependency when linking to the shared library using the static flags.
I couldn't actually do a complete stand-alone test with r1862 because it wouldn't build on my machine - see output below. (My guess is that r1859 is causing the problem. Maybe the shift left is overflowing on x86_64 giving zero?)
Regards, Phil
./polyimport -H 50 polytemp.txt -I . < ./exportPoly.sml
Value of -H option is too large -H <Initial heap size (MB)> --minheap <Minimum heap size (MB)> --maxheap <Maximum heap size (MB)> --gcpercent <Target percentage time in GC (1-99)> --stackspace <Space to reserve for thread stacks and C++ heap(MB)> --gcthreads <Number of threads to use for garbage collection> --debug <Debug options: checkmem, gc, x> --logfile <Logging file (default is to log to stdout)> Debug options: checkmem <Perform additional debugging checks on memory> gc <Log summary garbage-collector information> gcdetail <Log detailed garbage-collector information> memmgr <Memory manager information> threads <Thread related information> gctasks <Log multi-thread GC information> heapsize <Log heap resizing data> x <Log X-windows information> sharing <Information from PolyML.shareCommonData> locks <Information about contended locks> rts <General run-time system calls> make[2]: *** [polyexport.o] Error 1 make[2]: Leaving directory `/home/pclayton/SML/PolyML/svn/trunk/polyml' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/pclayton/SML/PolyML/svn/trunk/polyml' make: *** [all] Error 2
On 29/09/2013 13:49, Phil Clayton wrote:
Thanks for the update. The polyml.pc file appears to be generated as expected. Using one set of linking flags for shared and static libraries does not appear to matter actually: although unnecessary linker flags can create unnecessary library dependencies, ldd shows that there isn't any additional dependency when linking to the shared library using the static flags.
Thanks for checking it.
I couldn't actually do a complete stand-alone test with r1862 because it wouldn't build on my machine - see output below. (My guess is that r1859 is causing the problem. Maybe the shift left is overflowing on x86_64 giving zero?)
I had another look at that and I hope it's now fixed.
Regards, David
On 17 Sep 2013, at 17:57, David Matthews <david.matthews at prolingua.co.uk> wrote:
I have uploaded the source for Poly/ML 5.5.1 to the SourceForge site so it is now officially released. I still need to create installers for Windows. The release notes at http://www.polyml.org/docs/ReleaseNotes.html give a general overview of the changes over the last year. There have been no big changes which is the reason it's 5.5.1 rather than 5.6.
David _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
Thanks for the new release.
I have a few issues/questions.
1. I?ve noticed a change in evaluation behaviour between PolyML 5.5.0 and 5.5.1. Given the functions:
fun foo () = let val () = print "x\n" in SOME end
fun bar f = List.mapPartial (Option.compose (Int.~, f ())) [1, 2, 3]
then under 5.5.0 ?bar foo? gives us
x val it = [~1, ~2, ~3]: int list
whereas under 5.5.1 we get
x x x val it = [~1, ~2, ~3]: int list
What?s happening here?
2. I?ve installed Poly/ML 5.5.1 using MacPorts (Mac OS 10.8.5). When using polyc I get a couple of warning messages, i.e.
$ polyc -o foo foo.o
gives me
ld: warning: could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in area1 from vimpoly.o. To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie
Is there any way to suppress this? When using cc for linking, one can get rid of these messages by adding
-Wl,-no_compact_unwind,-no_pie
Is this advisable or is there a better solution?
3. I?ve managed to build HOL4 using 5.5.1 but we have lost our prompt. My understanding is as follows:
$ foo | poly
suppresses the prompt
$ foo | poly -i
brings the prompt back. However, if program ?bar? is based on using PolyML.rootFunction (as HOL4 is) then we get
$ bar
prompt
$ foo | bar
no prompt.
Since piping (a quotation filter) is used with HOL4, we get the latter. How do we implement the ?-i? option to get our prompt back?
Thanks, Anthony
On 20/09/2013 08:59, Anthony Fox wrote:
- I?ve noticed a change in evaluation behaviour between PolyML 5.5.0
and 5.5.1. Given the functions:
fun foo () = let val () = print "x\n" in SOME end
fun bar f = List.mapPartial (Option.compose (Int.~, f ())) [1, 2, 3]
then under 5.5.0 ?bar foo? gives us
x val it = [~1, ~2, ~3]: int list
whereas under 5.5.1 we get
x x x val it = [~1, ~2, ~3]: int list
What?s happening here?
This doesn't look good. I need to investigate further but it looks as though a bug has crept in during the work on the intermediate code optimiser.
- I?ve installed Poly/ML 5.5.1 using MacPorts (Mac OS 10.8.5). When
using polyc I get a couple of warning messages, i.e.
$ polyc -o foo foo.o
gives me
ld: warning: could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in area1 from vimpoly.o. To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie
Is there any way to suppress this? When using cc for linking, one can get rid of these messages by adding
-Wl,-no_compact_unwind,-no_pie
Is this advisable or is there a better solution?
I've done a search on this. It looks as though it has something to do with libffi (_ffi_call_unix64 is certainly part of libffi). I don't know if there's a newer version of libffi around that fixes this.
- I?ve managed to build HOL4 using 5.5.1 but we have lost our
prompt. My understanding is as follows:
$ foo | poly
suppresses the prompt
$ foo | poly -i
brings the prompt back. However, if program ?bar? is based on using PolyML.rootFunction (as HOL4 is) then we get
$ bar
prompt
$ foo | bar
no prompt.
Since piping (a quotation filter) is used with HOL4, we get the latter. How do we implement the ?-i? option to get our prompt back?
You should just be able to run "bar -i". PolyML.rootFunction decodes the arguments which it gets with CommandLine.arguments. You can, of course, implement your own top-level loop. It's actually very simple: all the real work is done with PolyML.compiler.
David
A follow-up on this.
On 20/09/2013 16:33, David Matthews wrote:
On 20/09/2013 08:59, Anthony Fox wrote:
- I?ve noticed a change in evaluation behaviour between PolyML 5.5.0
and 5.5.1. Given the functions:
fun foo () = let val () = print "x\n" in SOME end
fun bar f = List.mapPartial (Option.compose (Int.~, f ())) [1, 2, 3]
then under 5.5.0 ?bar foo? gives us
x val it = [~1, ~2, ~3]: int list
whereas under 5.5.1 we get
x x x val it = [~1, ~2, ~3]: int list
What?s happening here?
This doesn't look good. I need to investigate further but it looks as though a bug has crept in during the work on the intermediate code optimiser.
I've fixed this and another bug that appeared when I disabled the optimisation that was causing the problem. I've ported the fixes to the fixes branch. I'm a bit concerned about this because it's clearly generating incorrect code. Should there perhaps be another release fairly soon?
- I?ve installed Poly/ML 5.5.1 using MacPorts (Mac OS 10.8.5). When
using polyc I get a couple of warning messages, i.e.
$ polyc -o foo foo.o
gives me
ld: warning: could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in area1 from vimpoly.o. To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie
Is there any way to suppress this? When using cc for linking, one can get rid of these messages by adding
-Wl,-no_compact_unwind,-no_pie
Is this advisable or is there a better solution?
I've done a search on this. It looks as though it has something to do with libffi (_ffi_call_unix64 is certainly part of libffi). I don't know if there's a newer version of libffi around that fixes this.
It's a bit difficult to get any further with this at the moment. The only Mac OS X machine I have access to is running 10.8.0 and that doesn't seem to have the problem.
David
On 11 Oct 2013, at 13:51, David Matthews <David.Matthews at prolingua.co.uk> wrote:
A follow-up on this.
On 20/09/2013 16:33, David Matthews wrote:
On 20/09/2013 08:59, Anthony Fox wrote:
- I?ve noticed a change in evaluation behaviour between PolyML 5.5.0
and 5.5.1. Given the functions:
fun foo () = let val () = print "x\n" in SOME end
fun bar f = List.mapPartial (Option.compose (Int.~, f ())) [1, 2, 3]
then under 5.5.0 ?bar foo? gives us
x val it = [~1, ~2, ~3]: int list
whereas under 5.5.1 we get
x x x val it = [~1, ~2, ~3]: int list
What?s happening here?
This doesn't look good. I need to investigate further but it looks as though a bug has crept in during the work on the intermediate code optimiser.
I've fixed this and another bug that appeared when I disabled the optimisation that was causing the problem. I've ported the fixes to the fixes branch. I'm a bit concerned about this because it's clearly generating incorrect code. Should there perhaps be another release fairly soon?
Thanks. Yes, it is concerning. I have kept my main working version on 5.5 for now, so I'd certainly appreciate a quick 5.5.2 release.
- I?ve installed Poly/ML 5.5.1 using MacPorts (Mac OS 10.8.5). When
using polyc I get a couple of warning messages, i.e.
$ polyc -o foo foo.o
gives me
ld: warning: could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in area1 from vimpoly.o. To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie
Is there any way to suppress this? When using cc for linking, one can get rid of these messages by adding
-Wl,-no_compact_unwind,-no_pie
Is this advisable or is there a better solution?
I've done a search on this. It looks as though it has something to do with libffi (_ffi_call_unix64 is certainly part of libffi). I don't know if there's a newer version of libffi around that fixes this.
It's a bit difficult to get any further with this at the moment. The only Mac OS X machine I have access to is running 10.8.0 and that doesn't seem to have the problem.
I see. I don't think this a big problem. Things seems to be working fine with HOL4 under 5.5.1 on Mac OS. Those extra flags (above) are added to avoid these messages. It won't be long before 10.9.0 is released, so there's a chance that the warning messages will go/change.
Some minor changes were made to HOL4 to recover our "> " prompt, so that worked out fine.
Thanks, Anthony
On Fri, 11 Oct 2013, David Matthews wrote:
I've fixed this and another bug that appeared when I disabled the optimisation that was causing the problem. I've ported the fixes to the fixes branch. I'm a bit concerned about this because it's clearly generating incorrect code. Should there perhaps be another release fairly soon?
As you know the official release of Isabelle2013-1 is in the pipeline. Right now Isabelle2013-1-RC3 bundles Poly/ML 5.5.1 without any of the recent fixes. I don't mind to revert to Poly/ML 5.5.0 for the final Isabelle release, so you don't have to rush anything here.
I am on vacation from 17-Oct-2013 to 04-Nov-2013, which means I will be unavailable for the usual tests with Isabelle and AFP on all reachable platforms.
Makarius
-
acjf3＠cam.ac.uk -
alex.merry＠cs.ox.ac.uk -
David.Matthews＠prolingua.co.uk -
makarius＠sketis.net -
phil.clayton＠veonix.com -
Ramana.Kumar＠cl.cam.ac.uk -
ramunas.gutkovas＠it.uu.se