I recently made a cabal package which can be seen here
It consists of a library and a few small example programs using it. Everything builds and works as expected.
I wanted to build an executable in a new package which uses this library, however I continue to run into a linking error I can't decipher:
/my/path/RandomAgent/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/rlglue-0.2.1.1/libHSrlglue-0.2.1.1.a(Agent.o):(.text+0x34f1): undefined reference to `rlgluezm0zi2zi1zi1_Pathszurlglue_version1_closure'
collect2: error: ld returned 1 exit status
To make things simpler to diagnose I moved one of the examples programs into my new package and discovered even it won't build properly. You can find that version of the executable here.
From this I've concluded that the problem is likely in something I'm doing in my .cabal files, but I can't see what's wrong. The error also seems to refer to the Paths_rlglue module which cabal automatically generates for the first package.
Can anyone help me understand why I'm getting this error?
You need to include the Paths_rlglue module in exposed-modules or other-modules like any other module in your project so that Cabal will link it.
Cabal should be better about telling you what is going on, see https://github.com/haskell/cabal/issues/1746.
Looks like I missed something in the documentation for Paths_pkgname
If you decide to import the Paths_pkgname module then it must be
listed in the other-modules field just like any other module in your
package.
Adding Paths_rlglue to my library's other-modules fixed the issue. Hope this saves someone all the time I lost on this.
Related
I am using Asio in a Rcpp package, and am therefore using the package AsioHeaders.
I have added BH and AsioHeaders in the "LinkingTo" part of the DESCRIPTION file of my package. I have also added comments
// [[Rcpp::depends(BH)]]
// [[Rcpp::depends(AsioHeaders)]]
in my code. So normally, the linking should be fine when compiling the package.
And it is when I compile it on Linux. But when trying to compile it on Windows, I get linking errors that are solved by linking -lws2_32 and -lwsock32.
I am thus wondering, whether I should edit the Makevars file so that these are linked on Windows but ignored on Linux, or if I have done something wrong using AsioHeaders?
AsioHeaders maintainer here. Quick questions:
Which version of AsioHeaders? It just updated at CRAN. Is this a change from the new version (which would suprise me ...)?
Make sure you are not accidentally using Asio functionality from Boost which will require linking. See the three packages using AsioHeaders.
If your package is truly header-only then LinkingTo: is all you need. R will find the header directories for you. In particular, you do not need link instructions in src/Makevars* because, well, header-only.
Also, you probably meant // forward slashes for your C++ comments above...
I'm getting a linker error indicating that the linker was unable to open a file (a static library) and therefore it fails. I am having a very difficult time troubleshooting this error because I never told the linker to link to the file which it is failing to open.
I am telling the linker to link to several static libraries. Many of the libraries I am linking to are wxWidgets static libraries. I don't need ALL of the modules from wxWidgets, so there are some which I am linking to and many which I am not. The file which the linker can't open is 'wxbase31ud_net.lib'. Like I said, that file is not among the libraries I am linking to. My immediate thought was that this dependency was being introduced implicitly somehow, perhaps by one of the wxwidgets libraries I WAS linking to. I didn't think static linkage worked this way but I didn't have any other ideas. I have been investigating that possibility and I've found nothing which indicates that is the case.
I set the build output verbosity to maximum, and the 'wxbase31ud_net.lib' is never mentioned anywhere until the error is reported.
I confirmed in my cmake project that the file in question was never passed back to me from the FindWxWidgets module, and was never referenced in any of the lists of files I associate with the target.
I grepped through the entire project directory and found no reference to the file anywhere, including the cmake-generated project files (visual studio project files).
What could be causing the linker to try and open this file?
Edit: Also, to be clear, the error I'm seeing is LNK1104
it's probably from a #pragma comment(lib,"???") except in the case of wx the argument to the pragma may be complex macros and it will be difficult to grep. This particular one may be from setup.h with #pragma comment(lib, wxWX_LIB_NAME("base", "")). You should be solving this by adding the directory with the wx libs to the linker's search directories.
The answer by zeromus is correct, this is almost certainly indeed due to including msvc/wx/setup.h which contains #pragma comment(lib)s. Possible solutions:
Simplest: build all the libraries, this will solve the errors and it's not a problem to link with a library you don't use.
Also simple but slightly less obvious: predefine wxNO_NET_LIB when building your project, this will prevent the file above from autolinking this particular library. You may/will need to define more wxNO_XXX_LIB symbols if you're missing other libraries, of course.
Less simple but arguably the least magic too: stop using $(WXWIN)/include/msvc in your include path, then wx/setup.h under it won't be included and nothing will be linked in automatically. The drawback is that you will have to specify all the libraries you do need to link with manually.
I've looked around (including StackOverflow), but the only question close to mine, as far as I can tell, is specific to Windows distributables, which doesn't apply to me.
I want to release a library: MyLibrary.lib
It uses some third-party libraries, for instance, ZMQ
I've included the third-party library into MyLibrary both with either #pragma or actually adding it to the project.
Either way, MyLibrary.lib compiles fine and creates a .lib file
HOWEVER.
An executable that is linked to MyLibrary complains at link time that it can't find the referenced ZMQ functions, as if ZMQ is not incorporated into MyLibrary.
Looking at MyLibrary with a hex editor it doesn't seem like ZMQ.LIB was incorporated. There are references to it but it seems "weak linked". I don't see the ZMQ code in there.
Alternatively, if I can get the application/executable to build and run it, it'll complain at runtime that it can't find zmq.dll.
Either way, it's obviously not in "MyLibrary".
How can I get a library to include other third-party libraries, so I don't have to distribute a bunch individually? What step am I missing?
Using MSVC2013
Thanks
Although I had the .lib I needed, it turns out it was an import lib, and the .dll was distributed elsewhere. I found the .dll and now it works. Thanks to all who responded.
What about the flags described in this article:
https://msdn.microsoft.com/en-US/library/2kzt1wy3%28v=vs.120%29.aspx
Can they help you?
How do I find the source of the code I am importing. Like if I do
λ <Prelude>: import Graphics.EasyPlot
λ <Prelude Graphics.EasyPlot>:
How do I find that code. I do not mean an online copy of the code (Google is very good at indexing Hackage by that) but where it is on my system that I can edit. The reason is that it is a bit buggy, and I want to try and fix it. (I might submit a patch, but I just want to fix it for my own use first.)
As #ThomasDuBuisson mentioned, you many not necessarily find that on your system. One thing which I generally do is fetch it using cabal:
cabal fetch package-name
It downloads the tarballs of the package. Once you have fetched it, the entire source will be under the path where cabal puts it. In my case, it is (/home/sibi/.cabal/packages/hackage.haskell.org/package-name ). You can then untar and then build it from the cabal file which is already present there.
That being said you should probably using the version control system which the project is using as #bheklilr pointed out.
When running Haskell programs that import several packages like this one:
import Text.Feed.Import
import Network.HTTP
main = do
page <- simpleHTTP (getRequest "http://stackoverflow.com")
print $ page
I get an error like this one (Note: This question intends to solve the general problem, this specific case is just an example) :
GHCi runtime linker: fatal error: I found a duplicate definition for symbol get_current_timezone_seconds
whilst processing object file
/usr/lib/ghc/time-1.4.0.1/HStime-1.4.0.1.o
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be
loaded twice.
GHCi cannot safely continue in this situation. Exiting now. Sorry
Reinstalling the packages (e.g. HTTP and feed in the above case) as described in this previous post doesn't help. How can I resolve this issue?
Why this error occurs
This issue is not specific to a single package (e.g. it was described here in relation to Yesod three years ago), but is caused by the different libraries you import (e.g. HTTP and feed) linking to different versions of a single library (this issue occurs only for libraries that export C-style symbols. Their symbol names are not unique. time is one of those packages.).
As denoted in the error message, the library that causes the issues in this specific case is time-1.4.0.1.
Diagnosing the exact problem
First, you need to identify which different versions exist of your library. You can do this by checking the packages using ghc-pkg describe <packagename>, or just take a look into your cabal installation directory (usually ~/.cabal/lib).
At the time of writing this, the issue was caused by both time-1.4.0.1 and time-1.4.1 being installed. By using ghc-pkg describe I figured out that feed (and only feed, in my case), linked to time-1.4.1 whereas about 100 libraries linked to time-1.4.0.1.
How to resolve
Identify the library version (of the library that causes the error, as denoted in the error message) as described above that fewer packages depend on. You'll need to rebuild all packages that depend on it. In my case this is time-1.4.1.
Then, uninstall the package:
$ ghc-pkg unregister time-1.4.1 --force
unregistering time-1.4.1 would break the following packages: feed-0.3.9.2 (ignoring)
Note that the feed package is now broken and needs to be rebuilt and reinstalled. After rebuilding however, it won't link to time-1.4.1 but time-1.4.0.1 (in my specific case). This re-linking will resolve the duplicate symbol problem.
$ cabal install feed
If the error still occurs after that, re-check all dependencies as described above. You need to make sure any library you import will show the same library it's linked to when analyzed with ghc-pkg describe <pkg>
Update: In order to find out, which packages depend on the problematic library, simply use ghc-pkg unregister without the --force flag (Thanks to John J. Camilleri for pointing that out!). Note that if no packages depend on said problematic package, it will be removed.
An alternative cause of the same problem, is when using common symbols in an external library, on windows. I have an issue with a fortran code base using the common symbols. It is better explained here> https://gitlab.haskell.org/ghc/ghc/-/issues/6107
This only happens in dynamic linking, so ghc works, but ghci does not.