Created attachment 229462 [details] patch Currently both flavors install headers and .cm files. This makes them to conflict each other. The attached patch removes conflicting files from the @x11 flavor allowing the executable to be installed in parallel with libraries. The executable seems to work in a standalone mode fine, but if it ever needs headers or .cm files the @shlib flavor can always be installed.
Approved, thank you for the investigation and fix.
Committed. Thanks for the quick approval!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=e3cf001d007c4aa6ed7ac45b7bf14982e2ecb3ce commit e3cf001d007c4aa6ed7ac45b7bf14982e2ecb3ce Author: Yuri Victorovich <yuri@FreeBSD.org> AuthorDate: 2021-11-13 21:49:26 +0000 Commit: Yuri Victorovich <yuri@FreeBSD.org> CommitDate: 2021-11-13 21:59:25 +0000 cad/ngspice_rework: Eliminate conflict between flavors Before both flavors installed headers and .cm files. This caused them to conflict with each other. This commit removes conflicting files from the @x11 flavor allowing the executable to be installed in parallel with libraries. The executable seems to work in a standalone mode fine, but if it ever needs headers or .cm files the @shlib flavor can always be installed. PR: 259809 Tested by: kevinz5000@gmail.com cad/ngspice_rework/Makefile | 19 ++++++++++++------- cad/ngspice_rework/{pkg-plist => pkg-plist-shlib} | 10 ++++------ 2 files changed, 16 insertions(+), 13 deletions(-)
a question: when @x11 and @shlib do not conflict each other, why is FLAVORS needed? why not removing FLAVORS, and installing the binary and the shared libs?
FLAVORS might not be needed here.
(In reply to Tomoyuki Sakurai from comment #4) Because ngspice's configure script lets you pick either shlib or x11, but not both. When building x11, it will not build shlib, and vice versa.
(In reply to Tomoyuki Sakurai from comment #4) In light of Kevin's answer it looks like your question is for ngspice upstream. They should allow to build everything in one shot.
just an idea: 1. run ./configure with_ngshared in do-configure 2. save config.status for shlib 3. run ./configure for x11 4. build with x11 in do-build 5. restore config.status for shlib 6. build again 7. manually install all the files in stage (not make install)
(In reply to Tomoyuki Sakurai from comment #8) That's a good suggestion. I could see making such a change to the FreeBSD port to support this. If you're familiar with the ports system, perhaps you could take a look first. Otherwise, I'll try to see what I can do about this soon (TM).
the PoC is here: https://github.com/trombik/freebsd-ports-ngspice_rework/commit/5609419134e02d6c8d7d5fc0daaa48a4479b0778 https://github.com/trombik/freebsd-ports-ngspice_rework/tree/main/cad/ngspice_rework `git diff ports..main` creates a patch.
Created attachment 235477 [details] ngspice_rework-36.log.gz (poudriere bulk with -t)
Thank you.
Created attachment 235496 [details] Patch WIP I've updated your suggested patch here. The main change was to rename pkg-plst-shlib to pkg-plist, because without the FLAVOR it was using the (empty) pkg-plist file. I'm currently debugging why the resulting shared library from this hack no longer loads with kicad: Failed to load shared library... Undefined symbol "g_mif_info"
sounds like LD_CONFIG issue. I haven't tested the port with Kicad yet.
building shlib first fixed it. fixed in: https://github.com/trombik/freebsd-ports-ngspice_rework/commit/9768ffdf5df10a0063c973f4c6882227cad366b4
(In reply to Tomoyuki Sakurai from comment #15) Thanks for investigating and writing up the fix. Do you know why changing the build order fixed it? I'll probably also do some testing on the CLI version to make sure that hasn't suddenly broken due to the build order...
the hint was a comment in PKGBUILD. "shared lib sets flags and modifies headers, needs dedicated pass" https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=ngspice-git#n37
(In reply to Tomoyuki Sakurai from comment #17) You were missing a change from 36 to 37: diff --git a/cad/ngspice_rework/Makefile b/cad/ngspice_rework/Makefile index e1ff6bc6b0ff..18b3ea1767f8 100644 --- a/cad/ngspice_rework/Makefile +++ b/cad/ngspice_rework/Makefile @@ -56,7 +56,7 @@ post-install: ${INSTALL} -d ${STAGEDIR}${PREFIX}/include/ngspice ${INSTALL_LIB} ${WRKSRC}/src/.libs/libngspice.so ${STAGEDIR}${PREFIX}/lib/ ${INSTALL_LIB} ${WRKSRC}/src/.libs/libngspice.so.0 ${STAGEDIR}${PREFIX}/lib/ - ${INSTALL_LIB} ${WRKSRC}/src/.libs/libngspice.so.0.0.2 ${STAGEDIR}${PREFIX}/lib/ + ${INSTALL_LIB} ${WRKSRC}/src/.libs/libngspice.so.0.0.4 ${STAGEDIR}${PREFIX}/lib/ ${INSTALL_DATA} ${WRKSRC}/src/include/ngspice/sharedspice.h ${STAGEDIR}${PREFIX}/include/ngspice/ ${INSTALL_DATA} ${WRKSRC}/ngspice.pc ${STAGEDIR}${PREFIX}/libdata/pkgconfig/ Other than that, I can confirm that the shared library and executable both work. Tomoyuki, the man page install location is now technically incorrect, because FreeBSD wants man pages in ${LOCALBASE}/man and not ${LOCALBASE}/share/man (Yuri could you confirm that?) Yuri, what's the procedure for poking the consumers of the shlib flavor? Should we suggest a patch to fix all dependent ports?
(In reply to Kevin Zheng from comment #18) Hi Kevin, > [...] FreeBSD wants man pages in ${LOCALBASE}/man and not ${LOCALBASE}/share/man [...] FreeBSD now recommends share/man for manpages actually. They changed the location not long ago. But both are acceptable at the moment. > [...] what's the procedure for poking the consumers of the shlib flavor? [...] I can just flatten the flavors in dependency lines, no worries. Yuri
Created attachment 235535 [details] Patch Here is the final patch with all the proposed changes squashed. I approve it, and if Yuri can give it a look-over and update the dependent ports, I think it's ready.
(In reply to Kevin Zheng from comment #20) Thanks, Kevin. Will look at it today. Yuri
I added the suggestion for the upstream to allow to build in one shot (the URL field). Let's wait for them to comment on it on the off chance that this is already implemented and we just couldn't see it. Yuri
The answer that the upstream gave supports the idea that libngspice and ngspice are two separate invocations of the simulator and should be kept as separate flavors. Perhaps flavors should be renamed. See https://sourceforge.net/p/ngspice/bugs/599/
the justification sounds like a historical design flaw to me. if they don't depend each other, they should have a different name of their own. anyway, i don't need x11 version in practical usages. just thought usage of FLAVORS seemed wrong. it's up to the maintainer.
I'm on the fence, so I'd like to hear everyone's thoughts. We don't necessarily have to do what upstream insists on doing. Pros to flavors: - Can install library without TUI application (which requires X11) Cons to flavors: - Conflicts in headers and .cm files. We technically don't need to install the headers in the TUI mode, but the .cm files are needed for code models to work (in both modes?) An alternative would be to make yet another flavor, e.g. ngspice_rework-shared, with the header files and code models.
i'm a kicad user. i guess, most of users are, too. i need a simulator in kicad. kicad requires x11. the port is required by kicad only the last time i checked. there might be users who do not need x11, but just the shared library. i cannot think of any use case, but theologically, there might be. to me, as a kicad user, the fact that the default ngspice_rework package does not provide shared lib was a surprise. the conflict was also a surprise. every change breaks someone's workflow. if you think backward compatibility is more important, keep the port in the ports tree. it will not surprise anyone.
There is a new and very promising Qucs-S (cad/qucs-s) circuit simulator GUI and it uses ngspice as a default simulator backend. Qucs-S doesn't require x11 in ngspice.
Let's go ahead and commit this patch to remove flavors and install the TUI and shared library in one port. We can add an OPTION to remove X11 if someone reports that there is a need.