小编AlQ*_*ist的帖子

我在Microsoft Windows(64位),内部目录C:\MinGW(MSYS目录是C:\MinGW\msys\1.0)上安装了MinGW和MSYS .我从官方ftp下载了最新的GNU Scientific Library(GNU GSL)软件包.

我已经使用MSYS执行configure并make成功执行INSTALLGSL包中的文件.这意味着,在MSYS命令行界面的MSYS home目录中,我插入了:

$ ./configure
$ make
$ make install

这产生了local在MSYS目录(目录下C:\MinGW\msys\1.0),包括目录bin,include,lib,和share.

我已经成功地编译的示例程序(其计算为$贝塞尔函数$ J_0(x)的$ x值= $ 5)根据在所述指令GSL手册,由

$ gcc -Wall -I/usr/local/include -c example.c

这会产生一个目标文件example.o,如预期的那样,没有任何错误消息.

目标文件被链接,根据指令通过

$ gcc -L/usr/local/lib example.o -lgsl -lgslcblas -lm

这将生成一个a.exe可在MSYS环境中执行的可执行文件.但是,在Windows命令行界面中cmd.exe,尝试运行可执行文件会出现以下错误消息:

程序无法启动,因为您的计算机缺少libgsl-0.dll.尝试重新安装该程序以解决此问题.

我想知道遗失了什么？应该怎么做才能生成可执行文件？

考虑以下代码片段，它定义了一个函数foo，该函数接受一个列表并对列表执行一些操作（如排序）。我尝试将片段加载到ghci：

-- a function which consumes lists and produces lists
foo :: Ord a => [a] -> [a]
foo [] = []
foo (x:xs) = xs

test1 = foo [1, 2, 3] == [2, 3]
test2 = null $ foo []

但出现以下错误：

No instance for (Ord a0) arising from a use of ‘foo’
    The type variable ‘a0’ is ambiguous
    Note: there are several potential instances:
      instance (Ord a, Ord b) => Ord (Either a b)
        -- …

我需要一个QTableWidget基于 aQTabelModel并QTableView在表格上方添加一些按钮。见下图：

QTableWidget应调整的宽度，使其不小于合理的最小值，并且不会超出其上方的按钮；特别是，第 1、2、4 列的大小应根据其内容进行调整，第 3 列Aberrations应扩大以填补右侧的空白。我想知道如何在代码中做到这一点。

以下是我用于自定义QTableWidget（PyQt5、Python3）的代码的最小示例：

from PyQt5 import QtGui, QtCore, QtWidgets
import numpy as np

#-- Table Model
class MyTableModel(QtCore.QAbstractTableModel):

    def __init__(self, data, parent=None, *args):
        super(MyTableModel, self).__init__(parent)

        # table data
        self.table_data = data
        self.rows_nr, self.columns_nr = data.shape

        # vertical & horizontal header labels
        self.hheaders = ["Head-{}".format(i) for i in range(self.columns_nr)]
        self.vheaders = ["Row-{}".format(i) for i in range(self.rows_nr)]

    # nr of rows
    def rowCount(self, parent):
        return self.rows_nr …

我对共享库的二级依赖有疑问。\n假设我们有以下依赖树：

libA.so\n\xe2\x94\x9c\xe2\x94\x80libB.so\n\xe2\x94\x94\xe2\x94\x80libC.so\n  \xe2\x94\x94\xe2\x94\x80libD.so\n

也就是说，共享库 A 依赖于共享库 B 和 C，而共享库 C 本身依赖于共享库 D。一个很好的例子是libCGSL共享库，它依赖于 CBLAS。

为了制作一个自给自足的易于使用的包并避免安装的共享库的不同版本出现问题，我将库libB、libC和libD与libA、 和 一起打包，如 Drepper\xe2\x80\x99s文章, \xe2中所述\x80\x9c如何编写共享库\xe2\x80\x9d (2011)，我添加了链接标志-Wl,-rpath,\\$ORIGIN --enable-new-dtags来设置 的RUN_PATH，libA.so这样动态加载器就可以在相应目录中找到 的依赖项libA，而不需要设置LD_LIBRARY_PATH（其中有它的缺点）。

问题是，设置RUN_PATHinlibA对辅助依赖项没有帮助，例如libD.so。\n打开动态加载程序调试消息（通过设置）表明加载程序尝试仅在标准LD_DEBUG库位置中查找，而不是在(与查找或 的作用相反）。libD.solibAlibBlibC