Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#61581 closed defect (worksforme)

xcrysden @1.6.2 build failure on Big Sur

Reported by: jakoboo (Jakub Bąbelek) Owned by: dstrubbe (David Strubbe)
Priority: Normal Milestone:
Component: ports Version: 2.6.4
Keywords: bigsur x11 Cc:
Port: xcrysden

Description

Installation fails on big sur.

--->  Computing dependencies for xcrysden
--->  Fetching archive for xcrysden
--->  Attempting to fetch xcrysden-1.6.2_0+gcc10.darwin_20.x86_64.tbz2 from https://cph.dk.packages.macports.org/xcrysden
--->  Attempting to fetch xcrysden-1.6.2_0+gcc10.darwin_20.x86_64.tbz2 from https://nue.de.packages.macports.org/xcrysden
--->  Attempting to fetch xcrysden-1.6.2_0+gcc10.darwin_20.x86_64.tbz2 from https://packages.macports.org/xcrysden
--->  Fetching distfiles for xcrysden
--->  Attempting to fetch xcrysden-1.6.2.tar.gz from https://cph.dk.distfiles.macports.org/xcrysden
--->  Verifying checksums for xcrysden
--->  Extracting xcrysden
--->  Applying patches to xcrysden
--->  Configuring xcrysden
--->  Building xcrysden
Error: Failed to build xcrysden: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_xcrysden/xcrysden/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port xcrysden failed

Attachments (1)

main.log (169.5 KB) - added by jakoboo (Jakub Bąbelek) 3 years ago.

Download all attachments as: .zip

Change History (25)

Changed 3 years ago by jakoboo (Jakub Bąbelek)

Attachment: main.log added

comment:1 Changed 3 years ago by jmroot (Joshua Root)

Keywords: bigsur added
Owner: set to dstrubbe
Status: newassigned
Summary: Failed to install on Big Surxcrysden @1.6.2 build failure on Big Sur

comment:2 Changed 3 years ago by dstrubbe (David Strubbe)

Looks like the same issue as #58681. Try the suggestion at the bottom there.

comment:3 in reply to:  2 Changed 3 years ago by jakoboo (Jakub Bąbelek)

Replying to dstrubbe:

Looks like the same issue as #58681. Try the suggestion at the bottom there.

Thank you, it fixed the build failure but I can't run it anyways. I guess it's not a problem with MacPorts tho and I should contact xcrysden developer right? The same error happened when I downloaded binary from the official website.

+-----------------------------------------------------------------+
|*****************************************************************|
|*                                                               *|
|*  XCrySDen -- (X-Window) CRYstalline Structures and DENsities  *|
|*               =         ===         =              ===        *|
|*---------------------------------------------------------------*|
|*                                                               *|
|*    Anton Kokalj (tone.kokalj@ijs.si)                          *|
|*    Jozef Stefan Institute, Ljubljana, Slovenia                *|
|*                                                               *|
|*    Copyright (c) 1996--2019 by Anton Kokalj                   *|
|*                                                               *|
|*****************************************************************|
+-----------------------------------------------------------------+

  Version: 1.6.2

  Please report bugs to: tone.kokalj@ijs.si


  TERMS OF USE:
  -------------
  XCRYSDEN is released under the GNU General Public License.

  Whenever graphics generated by XCRYSDEN are used in scientific
  publications, it shall be greatly appreciated to include an explicit
  reference. The preferred form is the following:

  [ref] A. Kokalj, J. Mol. Graph. Model., Vol. 17, pp. 176-179, 1999.
        Code available from http://www.xcrysden.org/.

XCRYSDEN_TOPDIR=/opt/local/share/xcrysden-1.6.2
XCRYSDEN_SCRATCH=/var/folders/wv/q0j3_bk10hn_gpq8bsjk5qq40000gn/T/

application-specific initialization failed: couldn't connect to display ":0"
Error in startup script: can't read "xcrys(platform)": no such variable
    while executing
"if { $xcrys(platform) == "windows" } {
    # testing ...
    rename exec _tcl_exec

    proc exec {args} {
	global env

    	# first try a normal exec..."
    (file "/opt/local/share/xcrysden-1.6.2/Tcl/cygwin.tcl" line 19)
    invoked from within
"source $system(TOPDIR)/Tcl/cygwin.tcl"
    (file "/opt/local/share/xcrysden-1.6.2/Tcl/xcInit.tcl" line 449)

comment:4 Changed 3 years ago by mf2k (Frank Schima)

It works for me on Big Sur. That error means that you don't have an X11 server installed. Install the xorg-server port, reboot and try again.

comment:5 Changed 3 years ago by kencu (Ken)

someone suggested we could make xorg-server a runtime dependency for the x11 subsystem to prevent these recurring simple but frustrating issues from tripping people up.

comment:6 in reply to:  4 Changed 3 years ago by jakoboo (Jakub Bąbelek)

Replying to mf2k:

It works for me on Big Sur. That error means that you don't have an X11 server installed. Install the xorg-server port, reboot and try again.

Thanks but it's still not working for me, did it then rebooted and I still have the same error.

The following ports are currently installed:
  xorg-server @1.20.9_0 (active)

comment:7 Changed 3 years ago by kencu (Ken)

try. this method, to help narrow down where your problem lies.

Install xterm.

sudo port install xterm

run the X11.app from the /Applications/MacPorts directory.

open xterm from that running application using the menu item under "File".

type into xterm the name of the x11 executable you want to run.

comment:8 in reply to:  7 Changed 3 years ago by jakoboo (Jakub Bąbelek)

Ok so i run 'Terminal' under 'Applications' ('File' was missing) and then typed xcrysden and it worked. Is there any way I can make it work like it used to? By just typing xcrysden into my normal terminal.

comment:9 Changed 3 years ago by kencu (Ken)

ok, so now we know approximately where the issue is.

comment:10 Changed 3 years ago by kencu (Ken)

the x11 apps do launch from the terminal, invoking X11.app to run and serve as their display server, use xinit and some scripts that the Apple engineer behind all this wrote up. He also wrote the XQuartz.app and set up the website that provides that, and he contribute Apple fixes to the xorg-server project upstream. He's become way too busy to handhold people around here any longer, although in past years he did a lot of that.

The sequence works generally fairly well. It does not work well at all on 10.4 Tiger, where the method I told you about is the only working method. On all the newer systems, it does work, but it can be broken.

If you ever installed XQuartz.app, remove any remnants of it, including any launch scripts, etc, it might have added. For this reason alone, MacPorts should bundle xorg-server and have it automatically installed when users install x11 apps, because when people have troubles, they install XQuartz.app and then things get promptly messed up. (FYI the only reason it is not installed is that we got into a silly "discussion" about the possible 1 person in 1 million who would want x11 apps installed on his Mac but no display server).

Then look through your startup scripts and remove anything that says anything about setting the DISPLAY.

Then reboot your system, and see if it works.

If it does, thank your lucky stars. If not, report back.

Once you get that working, there is a much much more complicated project that can be done to run the x11 apps on a different server -- I use Ubuntu -- and view them on the Mac using the X11.app as though they were running locally. That does work, but is about 10 x harder to set up than this.

comment:11 Changed 3 years ago by jakoboo (Jakub Bąbelek)

I did install XQuartz through brew before (gnuplot --with-x11) but xcrysden was working anyway till I updated to big sur. I uninstalled xquartz using 'brew cask uninstall --force xquartz' then did brew cleanup and it's still not working after reboot.

comment:12 Changed 3 years ago by kencu (Ken)

try to make sure that there is no residue of homebrew left, especially any launch scripts left in the system or user launchagents and launchdaemons and similar. This is most likely your problem, I think.

Then reboot, and if it still doesn't work, deactivate and reactivate the xinit port.

after that, if it still doesn't work, and you've inspected all your profile scripts, etc, then report back again.

comment:13 Changed 3 years ago by jakoboo (Jakub Bąbelek)

I uninstalled homebrew entirely, there's nothing left in launchagents and daemons and nothing in .zshrc, etc. I also reactivated xinit but xcrysden still won't work from my normal terminal (iTerm)

Last edited 3 years ago by jakoboo (Jakub Bąbelek) (previous) (diff)

comment:14 Changed 3 years ago by kencu (Ken)

and the xinit port? you deactivated and reactivated it? that is what makes the launching work.

comment:15 in reply to:  14 Changed 3 years ago by jakoboo (Jakub Bąbelek)

Did it (I edited my previous comment)

comment:16 Changed 3 years ago by kencu (Ken)

Just for completeness, try from Apple's Terminal.app and see if that works.

comment:17 Changed 3 years ago by jakoboo (Jakub Bąbelek)

Not working in Apple's terminal either. I even uninstalled macports, deleted /opt/local nad /usr/local installed it all again and it still shows the same error.

comment:18 Changed 3 years ago by jakoboo (Jakub Bąbelek)

I'll do a clean installation of MacOS, there isn't much on this machine and maybe it'll simply work after that... Will report back after that, but btw I have a question, what's the best way to handle both macports and homebrew? I know it's not recommended but I need it and maybe there's just a better way than the standard one (homebrew installs by default to usr/local).

comment:19 Changed 3 years ago by kencu (Ken)

Because homebrew installs into /usr/local, the system and compilers will find their stuff and use it, even if you have no intention of that happening.

This makes things a bit easier (ergo why homebrew became popular) but it's just plain wrong, and causes lots of wreckage.

Homebrew knows this, and they have realized they have to abandon /usr/local and move to /opt/homebrew. This is a huge process of sorting out how to make software properly obey paths to include files and libraries, and MacPorts has already had this totally sorted out for nearly 20 years. You can expect homebrew to have many birthing pains here, and likely try to copy or duplicate MacPorts extensive tooling.

Can I ask what exactly you feel you need homebrew for? I have not found a single thing that it can do that MacPorts doesn't do better, but if you have some specific piece of software you need, and it's possible to port it, we will help you out.

comment:20 Changed 3 years ago by kencu (Ken)

Also, for what it's worth, MacPorts runs on every MacOS version from 10.4 Tiger PPC to the newest arm64 mac.

I just installed Octave 5.2 on 10.4 Tiger to allow that machine do so some math work here in the house.

homebrew cuts you off hard at three systems. Which is great for all my Apple stock, to be honest, but not so great for the landfill (Ubuntu aside).

comment:21 Changed 3 years ago by jakoboo (Jakub Bąbelek)

Well there isn't a specific piece of software that I need homebrew for that I couldn't get by other means, but I do web development and (from my experience) community is heavily skewed towards it. So it's more peer pressure than personal preference and not wanting to be "that guy" in the office.

comment:22 Changed 3 years ago by dstrubbe (David Strubbe)

Keywords: x11 added

At any rate, to summarize for anyone looking at this ticket in the future, the problem you are reporting is about use of X11 (perhaps in presence of homebrew), and not about xcrysden.

comment:23 Changed 3 years ago by kencu (Ken)

Resolution: worksforme
Status: assignedclosed

Yeah -- his initial build failure was due to an ld64 misconfiguration. We can close this ticket from that point of view.

The X11 stuff, if it still goes on after his reinstall, is better managed on the user mailing list I suppose.

comment:24 Changed 3 years ago by kencu (Ken)

Jakub, this launching issue was sorted out and turned out to be due to a minor bug in base, setting a DISPLAY variable in your .zprofile on 11.x when it should not have done.

If you remove any such setting you should be OK after a reboot (or relogin, for the person who is going to point that out).

New base will be coming out eventually.

Note: See TracTickets for help on using tickets.