http://community.activestate.com/node/7011
It's kinda like that poor chap shang (can I use chap gender-neutrally?) over there in the link, except it's another year and I have MSVS 2012.
Details
CMake has placed C:...\Tcl\lib\tcl85.lib on the dependencies list for my binary (I checked in the generated .vcproj file - it's there). Nevertheless, the linker errors are numerous and of the form:
nativeTCL_wrap.obj : error LNK2019: unresolved external symbol __imp__Tcl_[some-command-name] referenced in function _SWIG_Tcl_[some-other-command-name].
So I check the header file as listed in the dependencies list for my project in MSVS: version is #define as 8.5. This matches the library that I'm trying to link to. I tried exploring tcl85.lib with dependency walker. Apparently it can't explore that kind of file. I ran dumpbin.exe on it... And the .lib file has ALL OF THE MISSING FUNCTIONS, but of the following form:
__imp_Tcl_[some-command-name]
It has all of the symbols... But there's an underscore missing in each of them!
I then explored the libtcl85.dll.a file given by ActiveState's Tcl distro used in Cygwin, and the symbols look like this:
__imp__Tcl_[some-command-name]
So it has the extra underscore, and the binary links properly on Cygwin.
...
This is seriously one of those moments where I'm throwing my hands up in the air and thinking, "What do?" in all of its simplistic grammatically screwed up glory. The same swig interface file with the same CMake generates a module successfully in Cygwin. But developing Cygwin is a pain in the ass because of how slow it is (builds are almost 5-8 times as long as in more native-Windows-ish systems).
What Happens Next?
Do I try to convince Swig to generate with dependencies with one less underscore? If so how? Do I give up and file a bug report? If so, where? Is this a bug in ActiveState Tcl? Is this a bug in Swig? Is this not a bug at all and I'm just screwed?
For the lack of an underscore the kingdom was lost?
So, as I was writing my question, I started thinking about all of the different alternatives to how this could have gone wrong. Then I remembered that CMake by default chooses the 32-bit version of MSVS. I am now feeling quite sheepish, but as someone else apparently had a similar problem on the ActiveState fora, I'm leaving my answer here for anyone else needing this little, tiny, itsy bitsy reminder...
As it turned out, selecting the 64-bit version of MSVS with cmake -G "Visual Studio 2012 Win64" fixed everything. Linking worked fine. The binary got loaded successfully into Tclsh.
I would've expected a more comprehensive error message from my build tool about trying to link 32-bit and 64-bit binaries together, though...
Related
Currently, cabal repl is unusable for me. Typing at the prompt is erratic: a few letters appear, then it seems to hang for 5-10 seconds, only to proceed again afterwards. I suspect it's related to the fact that it loads Alex/Happy generated files (81K and 134K respectively) into the REPL. I don't really need those files for REPL support most of the time. I'm not sure if that's actually the problem, but I don't know what else to try.
I'd like to be able to exclude them from the REPL while still including them in the build process. Even better: can I only use one function from each of those files (lex/parse) somehow?
Edit: I'm seeing this behavior with GHC 7.8.3/Cabal 1.20.0.3 running on OS X 10.9 and a mid-2012 rMBP (Sandy Bridge) with 16GB of RAM. GHC/Cabal was installed via Homebrew.
Edit 2: Cabal file in question
Can you post your .cabal file?
If I understand your situation correctly, here's how I might proceed:
Verify that the alex and happy generated files are causing the slowdown.
If that is the case, consider moving them into a different package so that ghci will load the compiled versions of them.
For #1, I might try replacing the alex and happy generated files with just stubs - skeletal files which contain definitions (= undefined) for only the symbols which are imported by other modules.
I tried reorganizing the code per user5402's answer, but I wasn't able to get much of a speedup, even with code in different base packages.
Instead, I created a .ghci file in the project directory with the following contents:
:set -fobject-code
This loaded compiled versions of modules, with only the exported functions callable. For my uses, this is fine.
I am new to F#. I get the following error when I attempt to build my F# project in Monodevelop:
/home/greenrd/git/hello/hello: Error FS0229: Error opening binary file
'/usr/lib/mono/4.0/../../../../../usr/lib/mono/gac/kde-dotnet/4.1.0.0_194a23ba31c08164/kde-dotnet.dll':
Could not find a part of the path
"usr/lib/mono/gac/kde-dotnet/4.1.0.0_194a23ba31c08164/kde-dotnet.dll".
(FS0229) (hello)
I don't think this is due to the 260 character file path limit in .NET, for the simple reason that the file path is only 102 characters. What could be the problem? file says:
/usr/lib/mono/4.0/../../../../../usr/lib/mono/gac/kde-dotnet/4.1.0.0__194a23ba31c08164/kde-dotnet.dll:
PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS
Windows
I don't even know where this filename comes from, I didn't enter such a strange filename anywhere. All I did was add the KDE C# bindings as a reference to the project.
This looks like a bug in the compiler when there are more .. than required - it looks like in this case the compiler drops the leading slash.
Changing the reference to
/usr/lib/mono/gac/kde-dotnet/4.1.0.0__194a23ba31c08164/kde-dotnet.dll
works just fine.
I am trying to chase this error up. Hopefully I will have a compiler patch today or tomorrow.
So after chasing a whole stack of functions in the compiler, it turns out this is actually a mono bug. This simplest way to reproduce it is
new FileStream("/../bin/bash",FileMode.Open,FileAccess.Read,FileShare.ReadWrite);;
which should work, but doesn't.
Reported to mono: https://bugzilla.xamarin.com/show_bug.cgi?id=17083
EDIT: This is apparently fixed in the latest mono - https://bugzilla.xamarin.com/show_bug.cgi?id=17083
i am using scons for different compilers.
vc10 and renesas compiler.
if i compile the program by using env.program(---) am getting the link flags as
"link /nologo /subsystem:console /pdb:project.pdb /OUT:program.exe D:\build1\subdirA\subdirA.lib D:\build1\subdirB\subdirB.lib main.obj"
it is working for VC10 compiler. But for renesas(my microcontroller) compiler, i am getting an error like
"Cannot open file : "/OUT:program.exe""
it will accept " -output=program.abs" command when linking. how can i change that one. can you please tell me
when program is linking /OUT:program.exe is adding by default.
can you please tell me how to change that to "-output=program.abs"
Thank you
What you want to do is called cross-compile: compile a Renesas binary on Windows. Seems like what you have done is loaded the Windows VC10 toolset in SCons (SCons does this automatically unless told not to) and just changed the compiler binary, so SCons is still using the VC10 compiler/linker flags, which dont seem to be compatible. I had to do something similar once with SCons, where I cross-compiled Cavium Octeon in a Linux environment, but luckily for me almost all of the flags were compatible.
I dont know anything about Renesas, but if its compilation flags are more similar to another platform/toolset, then load those instead of Windows, as follows where Im loading the Linux gcc toolset.
env = Environment(tools = ['gcc'])
Look for Construction Environments in the SCons man page for a complete list of supported tools. Keep in mind that by doing this, you will no longer have support for the native platform toolset, Windows VC10 in your case.
When and if you find a similar platform, and you still need to change some compiler/linker flags or options, take a look at changing the related SCons Construction Variables. A few that could be helpful are: CXXFLAGS, LIBSUFFIX, LINKFLAGS, OBJSUFFIX, and PROGSUFFIX. The LINKFLAGS construction variable is actually the answer to your original question.
I did a google search for scons renesas, and came across this link which might also be helpful.
I've been using Libpng15 in Windows 7, but I've been getting errors in relation to the
Unresolved External _png_set_longjmp_fn error when I compile my code. I followed the directions in the aforementioned link, and while it DID compile without any errors, I wound up with a message saying that I needed libpng12.dll to continue.
So, I did some Googling for libpng12.dll...nothing came up but generic "find x.dll" websites which appeared to be scams.
I've tried reading the INSTALL docs for the libpng source code on their website, and all that I see is instructions on how to do it via Unix based systems. I tried to do this in Cygwin with no luck, so I'm kind of stuck on how to compile this library.
All in all, I'm willing to do either the compilation or just using the .dll, though the problem is that I can't find a working .dll for version 12.
Another thing I tried was downloading binaries from here, which claimed to be "libpng12 for windows". I then copied the files into my VC compiler directory, which overrode libpng15, I think. Still, when I link against it statically and run my program in VC, it says that I require the .DLL file. The libpng12.dll file was in fact a .dll.a file instead. I honestly am not sure to link these (I tried linking it statically by typing "libpng12.dll.a" in the Linker Input setting through VS).
If I can go the .dll route for libpng12, how do I do this? Where is the file? How do I link it in VS?
Any help would be appreciated, as it seems there really isn't a whole lot of information on this. Either that, or I'm just not looking properly.
Look in the "projects" directory of the libpng distribution, and use one of the visual projects.
As mentioned above Look in the "projects" directory of the libpng distribution
Then make the adjustments outlined here
https://stackoverflow.com/a/38547948/293792
Which I note here for simplicities sake
(as stated there) adding two lib values to
Config -> Linker -> Input -> Additional Dependencies
these values are ucrt.lib;vcruntime.lib
Ensuring the build type is /MD
Allowed me to build these older versions, and fix that error on Windows 10 VS2015.
This link seems to have an installer for 1.2 for you:
http://gnuwin32.sourceforge.net/packages/libpng.htm
it's 32 bit. Not sure if that makes a difference for you.
Error 2 error LNK1104: cannot open file 'OgreMain_d.lib' C:\Users\Owner\Documents\Code\C++\Test\ogrevcpp\ogrevcpp\LINK ogrevcpp
This is the error I get when trying to build an Ogre3D application (with steps followed from here).
I've followed everything to the T, yet I still get the error. It honestly shouldn't be happening. I've also followed everything from here.
Edit
What's happening is there are two different files, one is meant for release, the other is meant for debug. I need the one for debug mode to compile properly (which is OgreMain_d.lib).
Update
I figured out what the problem was - I was using the incorrect binaries; there was a few releases which were meant for Visual C++, and one which was meant for MinGW, along with a few other compilers. My apologies.
You need to check your library paths to make sure that the path where OgreMain_d.lib lives is part of the library path.
I guess the library for Debug mode is not present in the lib folder. Try putting two different libraries folder for each Assembly mode in Visual Studio. Go to ProjectProperties -> Configuration Properties -> Linker -> Additional Library Directories on Right hand. Make sure to check the Configuration Dropdown on the top.