I need to provide 32 and 64 bits version of my .dll for a customer. Do I need to generate 2 files? Or can a single one contain code for both architectures?
And for extra brownie points: does the same question apply for Mac libraries? Or the Universal Binary approach solve that issue?
Thanks in advance
Alex
You will need to provide two different dlls.
I believe that you will need to provide two different assemblies.
It depends on the platform and what is in the code.
With C/C++/... (native code) it will generally require different files, but some platforms may provide a way to package these together.
In "managed/visualised" systems (e.g. Java, .NET) you can have a single file that will work either way (the JIT/runtime handles the processor specific translation), but use of native interfaces (e.g. P/Inkvoke) will possibly fail in this case (e.g. structure field offsets change).
Related
I am combining two designs into a single chip design. The RTL code is written in SystemVerilog for synthesis. Unfortunately, the two designs contain a number of modules with identical names but slightly different logic.
Is there a namespace or library capability in SystemVerilog that would allow me to specify different modules with the same name? In other words is there a lib1::module1, lib2::module1 syntax I could use to specify which module I want? How is this sort of module namespace pollution best handled?
Thanks
Look into config and library. See IEEE Std 1800-2017 § 33. Configuring the contents of a design
library will map this files to target libraries based on file paths (IEEE Std 1800-2017 § 33.3. Libraries)
config will map which library to use for paralytic module (global, instances, subscope) (IEEE Std 1800-2017 § 33.4. Configurations)
Examples are provided in the section 33.8.
Note: some simulators want -libmap <configfile> in the command line. Refer to your simulators manual.
Unfortunately, neither verilog nor system verilog provide a comprehensive solution for the namespaces problem for design element (which include modules). V2K libraries and config statements (yes,they were introduced in verilog v2k) can partially help you solving this issue for modules only, and only if you plan for this in advance and use correct methodology to implement it. Not many people try to use v2k libs to solve it.
There are other parts of this as well, which you might discover. It include other design elements, macro names, file names, package names, ... System verilog makes it even worse with introducing of the global scopes.
So, depending on the complexity of your design you might be able to fix it with v2k libs. But in general, the solution always lies in the methodology and having those names uniquified upfront. Some companies even try to use on-fly uniquification by automatically rewriting verilog code in order to make those names unique.
You might also be able to solve some of the issues like that using compilation units, as defined in the SV standard and which are implemented at least by major tool vendors.
More as a curiosity, if I want to prevent some code from looking at the parent directory (contained in a list of files/directories) and I do something along the lines of (e.g. Perl) next if /^.+$/ to exclude . and .. , is this sufficiently cross-platform? If not, which platforms are different and how might one prevent accessing the parent in that case?
It will work in most modern platforms. (It will also exclude Unix hidden files/directories, but this is probably a good thing given the context.) Windows has a special case at the root of a drive, but it's not so much "different syntax" as "not there in any syntax"; if you have any intention of using platforms such as OpenVMS or Z/OS, it won't work at all.
Note that Perl and Python ship with cross-platform path utilities that you should use instead. I couldn't tell you about PHP or Ruby but I presume both also do so.
Doesn't work in ZX Spectrum. :)
Seriously, pretty much all platforms in current wide use (i.e. MSDOS, Windows, *NIX including Linux) conform to that. Be aware you will also be excluding hidden directories in UNIX-like systems.
I have a need to handle various rar/zip files, in Objective-C. Ideally I'd like to be as flexible as possible in terms of rar/zip versions. I'd also like to be able to only extract certain files from the rar/zip files, after pulling out a list of the file contents.
If that wasn't enough, I'd like to be able to access and modify the zip comment.
Is this easily possible in objective-c? I've searched around a lot and found a lot of half-finished libraries that don't do everything I want, or only support rar up to version 2, or don't support extracting single files.
I know I could just use the command line unzip tool that ships with MacOS Panther and up, but this seems inelegant and doesn't help me with rar files, as no unrar application ships with MacOS by default.
Can anyone point me at a decent library that does one or the other of these two types of files, or a recommended best approach for dealing with this problem? I know that one option is to wrap the unrar source, and also wrap the zlib source, but this to me is a daunting task. If there's no other option I'll do it - any advice or guidance on this would be gratefully received.
Thanks!
Yes, doing that it's easy in objective C. For zip files just use ZLIB (it's already included in Mac OS X.
RAR is not that simple though. Look for a C library (not an Objective-C library). There will be way more C libraries for RAR handling than Objective-C ones. And you can use all C libraries you want within an Objective-C program.
I have a C++ static library that supports both x32 and x64 platforms.
My question is: should I name the .lib file different depending on which platform?
i.e. MyLib32.lib vs MyLib64.lib
Intel Math library and TBB handle this using folder name to differentiate between the 2 libraries instead.
i.e. x32\Math.lib vs x64\Math.lib
Is there a better way compared to the other?
I think explicitly naming the lib to correspond to the intended platform should be better? That way we dont depend on folder name and the lib is self-documenting.
Be nice to your users and add 32 or 64 to the end like you propose. It's absolutely 100% clear what it means at first glance and you'll never mix them up.
I've been doing a lot of 32 and 64 bit work lately and I definitely prefer different names.
No, I don't think that one approach is superior to the other, and I think you've properly enumerated the two differences in each.
From my experience, however, many libraries have the same name, but are kept in either separate folders and are distributed in separate zip files.
LPSolve on sourceforge, for example, has their binaries named the same, regardless of platform.
Can someone here tell me if there is something similar to LD_PRELOAD on recent versions of AIX? More specifically I need to intercept calls from my binary to time(), returning a constant time, for testing purposes.
AIX 5.3 introduced the LDR_PRELOAD (for 32-bit programs) and LDR_PRELOAD64 (for 64-bit programs) variables. They are analoguous to LD_PRELOAD on Linux. Both are colon-separated lists of libraries, and symbols will be pre-emptively loaded from the listed shared objects before anything else.
For example, if you have a shared object foo.so:
LDR_PRELOAD=foo.so
If you use archives, use the AIX style to specify the object within the archive:
LDR_PRELOAD="bar.a(shr.so)"
And separate multiple entries with a colon:
LDR_PRELOAD="foo.so:bar.a(shr.so)"
AIX 5L uses the LDR_PRELOAD variable.
Not that I'm aware of. Closest thing we've done (with malloc/free for debugging) is to
create a new library file with just the functions desired (same name as original).
place it in a different directory to the original.
make a dependency from our library file to the original.
change the LD_LIBRARY_PATH (or SHLIB_PATH?) to put our library first in the search chain.
That way, our functions got picked up first by the loader, any we didn't supply were provided by the original.
This was a while ago. AIX 5L is supposed to be much more like Linux (hence the L) so it may be able to do exactly what you require.
Alternatively, if you have the source, munge the calls to time() with mytime() and provide your function. You're not testing exactly the same software but the differences for that sort of minimal change shouldn't matter.