On Fri, 10 Feb 2017 21:26:31 +0100 Guilherme Brondani Torri <[email protected]> wrote: > I also had to create a /usr/local/bin/gnucap.rc containing: > "load /usr/local/lib/gnucap/gnucap-default-plugins.dylib"
That's one way to do it. > > For some reason it would not find the plugins: > === > main version: unstable 2016.11.17 > core-lib version: unstable 2016.11.17 > load gnucap-default-plugins.dylib > ^ ? dlopen(gnucap-default-plugins.dylib, 6): image not found > libc++abi.dylib: terminating with uncaught exception of type Exception_CS > Abort trap: 6 > === Finding the plugins in a portable or automatically configurable way has been a problem. I have not found a way that I am completely satisfied with. If you have any ideas, please let me know. The various "plugpath" branches are attempts at some ways to deal with this. "plugpath", "plugpath+" add compiler options to set tags in the files. I could not make this work the way I think it should, and it only addresses one platform. "plugpath-2" and followups bypass the default search and explicitly specify it. I think this could be better, but doesn't work if whatever way to explicitly specify is missing. This should be easy to fix, so I am leaning toward this way, but it still needs work. Some issues ..... The file suffix .. .so , .dylib, .dll .... others? Aside from just the name match, having different suffix makes for an inconsistent user experience. The names are different on different systems. Should we make up a new suffix that is the same on all systems? dlopen search strategy seems to be different on different systems, and doesn't work the way the docs imply it should. The default search path sometimes requires the file name to begin with "lib". Originally, the default plugin collection file was "libgnucap-default-plugins.so", but we dropped the "lib" because it is intended to be loaded with dlopen, not automatically linked at startup. Actually, if it is renamed back to add the "lib" prefix, it can be linked at startup or static linked. A problem finding the file was introduced when we removed the "lib". Should we put it back? This is initially an issue with the default plugins, but really also an issue with plugins loaded by the user, or by gnucap.rc. Should the load command syntax just specify the base name, then let the software add a system dependent prefix and suffix to make the default search happy? > So, CMake is working for me. > > So far I haven't tried the Make1, Make2, Make3 makefiles. That's what I use. It's really just a plain Makefile in 3 parts. Make1 is specific to this program and not tied to the platform. Make2 configures to the platform, this computer. Make3 is boiler-plate, the same everywhere. The real Makefile is made by "cat Make1 Make2 Make3 >Makefile". Make2.xxxx are pre-configured versions of Make2, which can be used as alternatives without running ./configure when you want something specific. ./configure generates Make2. I find it a lot easier to work with than any of the automated configuration tools, but it doesn't have all of the options that some claim they need. To provide that would be just more stuff in Make3, but I haven't done it, wishfully hoping for one of the config tools to do what it is supposed to do in a clean modular way that does not get in the way. I would like to be able to think of configuration as like plugins, but it doesn't quite work that way. > I also tried fixing the autotools build, see [2] (which is now based on > [1]). > It builds fine but I am unable to run it. See bellow: > > >From the build directory: > === > [autotools-osx]~/git/gnucap $ ./main/gnucap > ./main/gnucap.real: line 117: > /Users/guitorri/git/gnucap/main/.libs/gnucap.real: cannot execute binary > file > ./main/gnucap.real: line 117: > /Users/guitorri/git/gnucap/main/.libs/gnucap.real: Undefined error: 0 > === > > After make install: > === > [autotools-osx]~/git/gnucap $ gnucap > -bash: /usr/local/bin/gnucap: cannot execute binary file > [autotools-osx]~/git/gnucap $ which gnucap > /usr/local/bin/gnucap > [autotools-osx]~/git/gnucap $ otool -L /usr/local/bin/gnucap > /usr/local/bin/gnucap: > .libs/gnucap.real (compatibility version 0.0.0, current version 0.0.0) > /usr/local/lib/libgnucap.0.dylib (compatibility version 1.0.0, current > version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 1238.0.0) > /usr/lib/libedit.3.dylib (compatibility version 2.0.0, current version > 3.0.0) > /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version > 5.4.0) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version > 307.4.0) > === > > How to proceed to get the functioning patches upstream? > Shall I split the patches targeting unstable, cmake and autotools branches? What the branches are .... "master" is considered stable. A tag represents a release. It is only changed by pushing unstable to master. "unstable" is the active development branch, but is not changed directly. Changes are done by merging topic branches when they are ready, always brought up for review on gnucap-devel before doing the merge. Other (topic) branches are where work is done. To be considered for merge, it must have the current unstable as an ancestor, so as to qualify for a "fast-forward" merge, but we actually merge with "no-ff" for logging. _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
