I have scons picking up a very odd dependency cycle. It goes something like this:
I have an object_file used in some_library which is used by some_executable in directory Fred/Jim and scons fails to buld, saying it has found this dependency cycle:
object_file -> some_library -> some_executable -> Fred/Jim -> Fred -> . -> object_file
for pretty much every object in that library, but not, as far as I can see, for every reference to that library.
More confusingly, we build this for both aix and solaris architectures, and only the solaris build does this, the aix build is fine.
I'm in the middle of migrating our build system, so it's probably something I changed recently, but I'm unsure as to where to look...
Ah, OK, I found it.
It's due to the subtle difference in python between
a = ('string')
and
a = ('string', )
The former produces a tuple of characters :-(
Related
I'm trying to compile a Salesforce sfdx plugin which is a node project with (among others) the following dependency chain that ultimately leads to fake-timers#^7.1.0:
#salesforce/command#2.2.0 -> #oclif/test#^1.2.4 -> fancy-test#^1.4.3 -> #types/sinon#* -> #sinonjs/fake-timers#^7.1.0.
When compiling it with the Typescript compiler tsc, I get the following error:
node_modules/#sinonjs/fake-timers/types/fake-timers-src.d.ts:11:28 - error TS2304: Cannot find name 'queueMicrotask'.
11 queueMicrotask: typeof queueMicrotask;
~~~~~~~~~~~~~~
Found 1 error.
error Command failed with exit code 1.
This looks like a bug in fake-timers-src.d.ts but introduced in 7.1.0 so I could try to lock the version at 7.0.5 but that might break all kinds of other things.
Does anybody who uses/maintains fake-timers know how to fix this? Or will this be fixed in a future version?
BTW I'm a total NodeJS n00b so if there's something really obvious here that I'm missing, please be kind and just tell me what it is :)
Thanks!
Frans
Frans! fatso83 from the Sinon team here :)
The problem here has all to do with TypeScript and nothing to do with Node, so I feel your pain. No wonder you are wondering. The problem is that the definitions are probably missing that property. For version 7 we tried to generate TypeScript definitions from JSDoc. This works reasonably well for simpler type, but ultimately, TypeScript is more powerful in describing types than JSDoc (like the typeof operator), so it was an uphill battle that would never result in the same quality as the types available from the external Definitely Typed project. We ended up abandoning that effort and therefore this will not be fixed, but it will naturally go away with version 8 (that will not be shipping its own types).
What you can do is this: npm install #sinonjs/fake-timers#6 (which is the previous version) and npm install #types/sinonjs__fake-timers#6 (which are the externally maintained types).
You might find some background for this in this issue.
I've got the following situation:
Library X is a wrapper over some code in C.
Library A depends on library X.
Library B uses Template Haskell and depends on library A.
GHC bug #9010 makes it impossible to install library B using GHC 7.6. When TH is processed, GHCi fires up and tries to load library X, which fails with a message like
Loading package charsetdetect-ae-1.0 ... linking ... ghc:
~/.cabal/lib/x86_64-linux-ghc-7.6.3/charsetdetect-ae-1.0/
libHScharsetdetect-ae-1.0.a: unknown symbol `_ZTV15nsCharSetProber'
(the actual name of the “unknown symbol” differs from machine to machine).
Are there any workarounds for this problem (apart from “don't use Template Haskell”, of course)? Maybe library X has to be compiled differently, or there's some way to stop it from loading (as it shouldn't be called during code generation anyway)?
This is really one of the main reasons that 7.8 switched to dynamic GHCi by default. Rather than try to support every feature of every object file format, it builds dynamic libraries and lets the system dynamic loader handle them.
Try building with the g++ option -fno-weak. From the g++ man page:
-fno-weak
Do not use weak symbol support, even if it is provided by the linker. By default, G++ will use weak symbols if they are available. This option exists only for testing, and should not be used by end-users; it will result in inferior code and has no benefits. This option may be removed in a future release of G++.
There is another issue with __dso_handle. I found that you can at least get the library to load and apparently work by linking in a file which defines that symbol. I don't know whether this hack will cause anything to go wrong.
So in X.cabal add
if impl(ghc < 7.8)
cc-option: -fno-weak
c-sources: cbits/dso_handle.c
where cbits/dso_handle.c contains
void *__dso_handle;
What are the possibilities, if any, for getting offline docs for Haskell core libraries (and maybe more)?
Sometimes I take my laptop to the coffee-shop where there is no wifi, and it would be nice having something like Hoogle but for offline use.
Hoogle is available offline, installable from Cabal: http://hackage.haskell.org/package/hoogle
Usage instructions are at http://www.haskell.org/haskellwiki/Hoogle#Command_Line_Search_Flags.
Usage:
$ hoogle --help
Hoogle v4.2.8, (C) Neil Mitchell 2004-2011
http://haskell.org/hoogle
hoogle [COMMAND] ... [OPTIONS]
Commands:
[search] Perform a search
data Generate Hoogle databases
server Start a Hoogle server
combine Combine multiple databases into one
convert Convert an input file to a database
test Run tests
dump Dump sections of a database to stdout
rank Generate ranking information
log Analyse log files
Common flags:
-? --help Display help message
-V --version Print version information
-v --verbose Loud verbosity
-q --quiet Quiet verbosity
Create a default database with hoogle data (more info at http://neilmitchell.blogspot.com/2008/08/hoogle-database-generation.html).
EDIT: A session of usage after installing Hoogle locally:
$ hoogle
No query entered
Try --help for command line options
$ hoogle data
(downloads databases...takes a few minutes)
I ran into an error here...apparently it is related to the version of Cabal, so I updated that (http://hackage.haskell.org/trac/hackage/ticket/811). That didn't help, so I ran hoogle data all, which I canceled since it was taking so long (it seems to go through every package on Hackage). It still wouldn't allow a query like hoogle map but did allow hoogle map +base (i.e. restrict the search to the base package) Hopefully it works for you!
EDIT2: This seems to fix the problem (for me):
$cd .cabal/share/hoogle-4.2.8/databases
$hoogle combine base.hoo
$hoogle foldl\'
Data.List foldl' :: (a -> b -> a) -> a -> [b] -> a
Data.Foldable foldl' :: Foldable t => (a -> b -> a) -> a -> t b -> a
The HTML documentation can be downloaded as .tar.bz2 from the Haskell website:
https://downloads.haskell.org/~ghc/latest/docs/
I just downloaded https://www.haskell.org/ghc/docs/7.6.3/libraries.html.tar.bz2 and it's exactly what I've been hoping for.
There are also other options, such as Dash and Zeal, and see also that reddit thread.
If you install the Haskell Platform it includes the GHC docs and the GHC library docs (which cover the core libraries). On Windows they are on the Start Menu under "All Programs|Haskell Platform".
Edit your ~/.cabal/config file. Look for the line (probably commented out) that says documentation: False. Change that line to documentation: True and uncomment it. Now when you build projects with cabal install documentation will also be built and saved locally.
Look around a little more in that same config file and you'll find things options like doc-index-file, docdir, datadir, prefix, etc that allow you to configure where the documentation is stored.
It may not be "canonical" per se, but i believe that the most useful option is a docset software like dash(OS X)/zeal + generated docsets. This way you'll get the search for free and also will have an option to build your custom docsets. It's no problem to get the 'base' package haddock documentation with either of the projects out of the box. You can build custom docsets with haddocset or dash-haskell. Also it integrates nicely with emacs/vim/other editors, allows you to have project-based docsets(you'll have the relevant versions on a per-project basis this way, forget all this hassle with local hoogle!) and don't restrict you to any build flow you can have.
If you build your project with cabal-install you can set documentation: True in your ~/.cabal/config, then reinstall dependencies to get generated haddocks locally.
If you're using stack, you can utilize stack haddock command to build your dependencies and project with generated haddocks.
I use devdocs.io, it has docs for a lot of languages and libraries (including Haskell) and has an offline mode.
Velocity is a free and beautiful universal tool to do just that. It supports a wide range of languages, technologies and libraries, and one click updating.
You will probably be able to find more of what you are already using in its documentation list.
For Windows, install cygwin's wget and curl packages. That will enable hoogle data.
If you happen to be using a Debian derived distribution and their packages, then you will find the combined documentation of all installed Haskell packages (if you also install the libghc-foo-doc packages) at
file:///usr/share/doc/ghc-doc/html/libraries/index.html
Furthermore, the libghc-foo-doc packages contain the necessary files for hoogle, so if you apt-get install hoogle, then you should immediately be able to use hoogle to search through all libraries installed this way.
I'm working on a project that creates a DLL in C for Windows CE 5.0 using STANDARDSDK_500. The project is relatively simple with just one C source file. What I've noticed is that when I clean and build the project using Visual Studio 2005, it fails to create my Import lib. When I tell Visual Studio to rebuild it, it correctly creates the import lib.
Turning on verbose linking, I discover that in the failure case (clean and build) CVTRES.exe is discarding my functions, like so:
Invoking CVTRES.exe:
/machine:thumb
/verbose
/out:"C:\...\Temp\lnkC7E.tmp"
/readonly
/windowsce
".\standardsdk_500 (armv4i)\release\WLTBApi.res"
Microsoft (R) Windows Resource To Object Converter Version 8.00.50727.42
...
adding resource. type:VERSION, name:1, language:0x0409, flags:0x30, size:892
Discarded '.idata$4' from coredll.lib(COREDLL.dll)
...
Discarded WLRegisterStartupApp from WLTBApi.obj // my functions! Oh noes!
...
This discards all of my functions, which causes the linker to not create an import lib because there are no exported functions.
I figured that the input was the .res file mentioned in the commandline - WLTBApi.res. This file is identical in the intermediate directory after trying to compile both the working way (rebuild) and the non-working way (clean. build).
So, my first question is: what are the other inputs to the CVTRES.exe program so that I can find discrepencies between the two builds?
Second: what other troubleshooting techniques would you recommend?
Additional Info - I thought perhaps the .obj files were additional inputs - they differ between the builds. I now believe that they are outputs of CVTRES.exe. If anyone knows whether or not I'm correct in this, let me know.
Okay, so I found a solution, but I'm terribly dissatisfied with it. I discovered that the project I was building had a Dependency, but one that wasn't actually a dependency. In other words, the project, WLTBApi was building a DLL, and had a dependency configured, WLTBApiLib, but it wasn't actually using any of the output of that project. By removing the dependency, the problem went away.
I'd still love to know more about how to find an actual answer to what was going on, but maybe this answer will help someone else in the future.
I have a set of statically-compiled libraries, with fairly deep-running dependencies between the libraries. For example, the executable X uses libraries A and B, A uses library C, and B uses libraries C and D:
X -> A
A -> C
X -> B
B -> C
B -> D
When I link X with A and B, I don't want to get errors if C and D were not also added to the list of libraries—the fact that A and B use these libraries internally is an implementation detail that X should not need to know about. Also, when new dependencies are added anywhere in the dependency tree, the project file of any program that uses A or B would have to be reconfigured. For a deep dependency tree, the list of required libraries can become really long and hard to maintain.
So, I am using the "Additional Dependencies" setting of the Librarian section in the A project, adding C.lib. And in the same section of B's project, I add C.lib and D.lib. The effect of this is that the librarian bundles C.lib into A.lib, and C.lib and D.lib into B.lib.
When I link X, however, both A.lib and B.lib contain their own copy of C.lib. This leads to tons of warnings along the lines of
A.lib(c.obj) : warning LNK4006 "symbol" (_symbol) already defined in B.lib(c.obj); second definition ignored.
How can I accomplish this without getting warnings? Is there a way to simply disable the warning, or is there a better way?
EDIT: I have seen more than one answer suggesting that, for the lack of a better alternative, I simply disable the warning. Well, this is part of the problem: I don't even know how to disable it!
As far as I know you can't disable linker warnings.
However, you can ignore some of them, using command line parameter of linker eg. /ignore:4006
Put it in your project properties under linker->command line setting (don't remember exact location).
Also read this:
Link /ignore
MSDN Forum - hiding LNK warnings
Wacek
Update If you can build all involved project in single solution, try this:
Put all project in one sln.
Remove all references to static libraries from projects' linker or librarian properties.
There is "Project Dependencies..." option in context menu for each project in Solution Explorer. Use it to define dependencies between project.
It should work. It doesn't invalidate anything I said before, the basic model of building C/C++ programs stays the same. VS (at least 2005 and newer) is simply smart enough to add all needed static libraries to linker command line. You can see it in project properties.
Of course this method won't help if you need to use already compiled static libraries. Then you need to add them all to exe or dll project that directly or indirectly uses them.
I don't think you can do anything about that. You should remove references to other static libs from static libs projects and add all needed static libs projects as dependences of exe or dll projects. You will just have to live with fact that any project that includes A.lib or B.lib also needs to include C.lib.
As an alternative you can turn your libraries into dlls which provide a richer model.
Statically compiled libraries simply aren't real libraries with dependency information, etc, like dlls. See how, when you build them, you don't really need to provide libraries they depend on? Headers are all that's needed. See? You can't even really say static libraries depend on something.
Static library is just an archive of compiled and not yet linked object code. It's not consistent whole. Each object file is compiled separately and remains separate entity inside the library. Linking happens when you build exe or dll. That's when you need to provide all object code. That's when all the symbol and dependency resolving happens.
If you add other static libraries to static library dependencies, librarian will simply copy all code together. Then, when building exe, linker will give you lots of warnings about duplicate symbols. You might be able to block those warnings (I don't know how) but be careful. It may conceal real problems like real duplicate symbols with differing definitions. And if you have static data defined in libraries, it probably won't work anyway.
Microsoft (R) Incremental Linker Version 9.00.x (link.exe) knows argument /ignore:4006
You could create one library which contains A, B, C & D and then link X against that.
Since it's a library, only object modules which are actually referenced will get linked into the final executable.
Note that one way of getting this warning is to define a member function in a header without the inline statement:
// Foo.h
class Foo
{
void someFunction();
};
void Foo:someFunction() // Warning! - should be "inline void Foo::someFunction()"
{
// do stuff
}
The problem is you are not localizing library C's symbols. So you have a ODR violation when you link in A and B. You need to have a way to make these private. By default all symbols are exported. One way to do this is to have a special linker definition file for both A and B that explicitly mention which files need to be exported.
[1] ODR = One Definition Rule.
I think the best course of action here will be to ignore/disable the linker warnings(LNK4006) since C.lib needs to be part of both A.Lib and B.lib and A.Lib does not need to know that B.lib itself uses C.Lib.
This may not fix your link error, but it might help with your dependency tree issue.
What I do, is just use a #pragma to include a lib in the .cpp file that needs it. For example:
#pragma comment(lib:"wsock32")
Like I said, I'm not sure it would keep the symbols in that object file, I'd have to whip up an example to try it out.
Poor flodin seems frustrated that nobody will explain how to disable the linker warnings. Well, I've had a similar problem, and for years I have simply lived with the fact that several hundred warnings were displayed. Now, however, thanks to the info from Link /ignore, I figured out how to disable the linker warnings.
I'm using Visual Studio 2008. In Project -> Settings -> Configuration Properties -> Librarian -> Command Line -> Additional Options, I added "/ignore:4006" (without the quotes). Now my warnings are gone!