In VHDL, I am getting an error that library "work" does not contain primary unit "clock_div".Library being used is "use work.clock_div.all;".
Have you compiled "clock_div" into the working library?
N.B "Work" should not be a real library, it refers to the library you're compiling the current module into.
So if you're working on an entity that you're compiling into a library called "components", and "clk_div" is already in that library, then use work.clock_div.all; and use cmoponents.clk_div.all; are equivalent.
However when you later build the top level design, without specifying a library, use work.clock_div.all; won't find "clk_div" because you're not working in the components library, while use components.clk_div.all; will.
Related
ALL,
I'm trying to figure out a proper link order when I build my software on Linux with gcc.
I have an .a library, which export an interface class (class with a lot of pure virtuals).
This a library is linked to libraryA.so and libraryB.so, because both those libraries have an actual implementation for the interface.
Now libraryB is also linked to unixODBC.
Now, both libraryA and libraryB are linked to libraryC, which actually instantiates the classes from them.
If I understand correctly the linking order should be as follows:
librarya.a libraryA odbc odbcinst libraryB
for libraryC.
But after successful build and running make install, trying to load libraryC fails, because libraryB is not visible.
Is my linking correct? Or better yet - is my understanding of the linking is correct - the referenced library should be first and then follows referencing libraries and I just need to update the LD_LIBRARY_PATH variable.
Thank you for clarifying.
I have asked this question on linux, but now I need the same info on macos... The question is (adapted to macos):
I am trying to create a shared library, libbar.dylib, that embeds a commercial static library (licensing is fine). The commercial library has 4 versions: libfoo-seq.a, libfoo-mt.a, libfoo-seq.dylib, and libfoo-mt.dylib (they all provide the same symbols, just the code is sequential/multi-threaded, and the lib is static/shared). Of these four I want my code always to use the sequential foo library, so when I create libbar.dylib I link together my object files and libfoo-seq.a.
The problem is that the users of my library may have already pulled in libfoo-mt.dylib by the time they pull in my libbar.dylib, thus all symbols from libfoo are already present by the time libbar.dylib is read in, so my calls to the functions in foo are resolved to the multithreaded version. At least I think this is happening. Is there any way to double check?
If this is really what is happening, I wonder how can I resolve this issue? What kind of magic flags do I need to use when I compile to create my object files and when I link my object files with libfoo-seq.a to create libbar.dylib?
I am trying to use fixed point numbers in my VHDL project, but I keep having trouble implementing the library (found here http://www.eda-stds.org/fphdl/fixed_pkg_c.vhdl). The error I receive when trying to simulate is this
<ufixed> is not declared
My question is how exactly should a library be implemented so it can be used? As of now I have added it to the project in the IEEE_PROPOSED library, but it is not working. All source code can be found here https://github.com/srohrer32/beamformer/tree/fixed_num, under the hdl folder and libraries folder.
Are you using modelsim? Are you using a project? If not... I find the best way is to first compile the library on its own. Open your modelsim.ini file and make a path to the library. Like this:
lib_test = c:/test/source/lib_test
Finally, compile your own code and make sure you use the -modelsimini switch on vcom modelsim command.
If you are using a project (which I don't like, they are not as flexible) then you can point the project to the library.
More help about modelsim compiling with commands:
http://www.tkt.cs.tut.fi/tools/public/tutorials/mentor/modelsim/getting_started/gsms.html#compiling
Not being an isim user myself, a search through the ISim User Guide implies you need to create a separate project to compile into a library, contrasting with how easy it is to target a library from the command line.
Presumably you'd also need to add the library as a resource in your project. Funny there are no complaints about that yet you have:
library ieee_proposed;
in delay_calculation.vhd, noting that a library declaration simply makes the name available. Somewhere the implementation dependent mapping for the library name to library needs to be made. This by default is in xilinxisim.ini, but I imagine your project management interface allows you to map the library into your project, and isim should know where to look for the library.
Nosing around the user guide may be worthwhile.
In Simulation Steps Overview
User Libraries
Depending upon how you launch ISim, there are different methods
available to add user libraries:
When launching Project Navigator, define the user libraries in the ISE tool. See “Working with VHDL Libraries” in ISE Help for
details.
When using ISim standalone, interactive command mode, or non-interactive mode, set the library mapping file (see Appendix A,
Library Mapping File (xilinxisim.ini) to point to your logical or
physical libraries.
When launching ISim from the PlanAhead tool, define the user libraries in that tool. See the PlanAhead User Guide (UG632) for more
information. Appendix D, Additional Resources, contains a link to the
document.
See Working with VHDL Libraries, see To Create a VHDL Library and To Add Files to a VHDL Library.
(The top level link to ISE Help).
You'd think there'd be a FAQ for those of us apostate - speed reading 'religious' tomes sucks even using Google to find them. Notice the explanations are in terms of menu pull down actions, analogous to command line entry. We're being bitten by what's available on the top menu bar. And when you do manage to add and use a library successfully you'll remember how until someone changes the menus around, and you could of course wonder about documentation lagging.
Presumably what you've tried to do is set up the library mapping for synthesis mode in the ISE GUI, which is straightforward but completely ignored by iSim since it has its own system for managing library mappings. I'm not an iSim user but after looking at the documentation and a little testing it looks like the easiest way to set up a library is from the command line:
# This creates an ieee_proposed directory with a partially compiled object.
vhpcomp --work ieee_proposed=ieee_proposed fixed_pkg_c.vhdl
# Add a mapping from the logical library to the physical path.
# *nix shown. Windows would be similar or just use a text editor.
# <logical name>=<physical path>
echo ieee_proposed=`pwd`/ieee_proposed >> path/to/your/xilinxisim.ini
Make sure the xilinxisim.ini file is visible to iSim and it should pick up the mapping to your compiled library. You should be able to keep running vhpcomp from the parent of ieee_proposed to add more files to the library. You may have to manually copy the system default version to maintain the standard library mappings.
My project is using ACE library, and need link another library libsdk.so, it's using another version ACE library.
The link order like : ...-lMyAce -lsdk -lAnotherAce
When application running, libsdk.so called method in MyAce(I checked the core dump), and the application crash.
If I change link order to: ...-lsdk -lAnotherAce -lMyAce
My code called method in AnotherAce, it's also crash.
If I only link my ACE, it's crash. There are some link error if only link AnotherAce.
Let the libsdk.so call its ACE library, and my code call my ACE library.
How can I resolve the problem?
The Solaris linker has an option that may help, though really redesigning your application to not need two sets of libraries with the same names in the same program
is going to be the best solution.
Direct Bindings record in each library or program which library it found a symbol in, so if libsdk.so is built with -B direct -lAnotherAce, it will record each of its references go to AnotherAce, not MyAce. You'd then link your code with -B direct -lsdk -lMyAce (do not include -lAnotherAce, as the libsdk dependencies take care of that), and your code would record that it's calls to to MyAce.
When I need to build some third party library to be used in several of my projects under different version of MSVC, I usually build it for every MSVC version and for both Debug and Release configurations. That's what boost does, and that's what we have been done for our whole life in my team.
However, I still don't get, why couldn't I just build this library with like... whatever. All I need is function prototype and object code, right? Since I'm linking CRT statically, I have no external dependencies. But when I'm trying to link library built in Release under MSVC8 with my project in Debug under MSVC10 I have this annoying "already defined" linker errors which we all hate so much.
But why? Can I just "encapsulate" all this functions inside lib and do not export them so that my project will take only what it needs from the lib? Why can I have precompiled version of libpng and zlib which I can link in every project? Yes, they are not build using MSVC, I guess, but the still uses the same functions of CRT. So can anyone please explain in depth or share a link to some enlightened explanation of this issue?
Since I'm linking CRT statically, I have no external dependencies
Well, that's not true, you do have a dependency. On the static version of the CRT. Debug or Release, depending on your build settings. And it is an external dependency, the linker glues the CRT later, when the library gets linked. The code that uses the library also has a dependency on the CRT. And if the compile settings don't match then the linker barfs.
You isolate that dependency by building a DLL instead of a static link library. You must further ensure that the exported functions don't cause a CRT dependency. You can't return a C++ object from the standard C++ library and can't return a pointer to an object that needs to be released by the client code. Even passing structures is tricky since their packing is an implementation detail, but you usually get away with it. A good practical example is COM automation, it forces you into using a subset of types that are universal. Windows is rife with them and all these servers work with any version of the compiler or CRT. Even any language. This however comes at a cost, writing such a library isn't as simple or convenient as just throwing a bunch of code in a static lib.