Code can be found in https://github.com/percona/percona-toolkit/tree/3.0.11/src/go/pt-mongodb-query-digest
/go/src/github.com/percona/percona-toolkit/src/go/pt-mongodb-query-digest: GOARCH=s390x go build
# github.com/percona/percona-toolkit/vendor/go4.org/reflectutil
../../../vendor/go4.org/reflectutil/swapper_unsafe.go:106:6: missing function body
../../../vendor/go4.org/reflectutil/swapper_unsafe_15.go:16:6: missing function body
Any idea on this issue
If you check the code of that dependency you will find:
103 // memmove copies size bytes from src to dst.
104 // The memory must not contain any pointers.
105 //go:noescape
106 func memmove(dst, src unsafe.Pointer, size uintptr)
The function is implemented in Assembly, in the asm_* files but it is not implemented for your platform (s390x). Also, you please be aware that (s390x) is not formally supported for Percona Toolkit either.
BTW, I am the Percona Toolkit maintainer.
go4.org/reflectutil does not have support for s390x. Making similar changes as in link for s390x worked for me.
Related
The title says it all. But, are there too many files to be replaced and is there a risk? What I mean is, there are files like d3d11.dll. Could I replace the files with with something like d3d12.dll or something like that?
When code is compiled it uses 'headers' and usually links to 'libraries' which refer to functions inside the dll. When the game loads it maps the DLL into the address space of the executable so that the program can use features in the DLL.
So if the Game does D3D11_DrawTriangles, it will end up calling that feature in d3d11.dll. Dropping in the DX12 DLL won't work because the expected function is no longer there (and besides, the executable would still be looking for the 11 DLL - it wouldn't even load).
Upgrading from DX11 to DX12 is a major undertaking; the graphics APIs are very different.
Put another way: It's like someone dropped a Fiat engine into your Volvo. Would it work? How much effort would it be to rewire all the pipes and electronics to make it work?
I try to develop a thirdparty unixODBC driver, it is a secondary development based on the original file libodbc.so.2.0.0.
so I want to rename 'libodbc.so.2.0.0' to 'libodbc.so.2.0.0_renamed'. And soft link my dynamic library file to libodbc.so.2.0.0.
But I found an issue bothering me, when I rename native file and run 'sudo ldconfig', the file named 'libodbc.so.2' automatically linked to the renamed file 'libodbc.so.2.0.0_renamed', as below:
I could not understand that:
why it occurs;
how to appropriately replace the library.
I don't have enough ackownledge about linux, so that I failed to get any keyword to search and deal with it.
Could you help me, thank you very much!
Shared objects under GNU/Linux follow a specific version naming scheme, which is known by the loader (and OS component, actually part of libc framework) to determine if a newer library is retro-compatible with some older version to which a binary was originally linked against. By adding the renamed suffix, you are violating the convention and the dynamic linking system is getting confused. You should renamed as suggested by #Bodo above.
In addition, perhaps rather than using rename, you might consider using the very versioning scheme. From GNU Build System (aka Autotools) manual, the version cheme is like it follows:
Versioning: CURRENT:REVISION:AGE
CURRENT The latest interface implemented.
REVISION The implementation number of CURRENT (read: number of bugs fixed...)
AGE The number of interfaces implemented, minus one.
The library supports all interfaces between CURRENT − AGE and CURRENT.
If you have
not changed the interface (bug fixes) CURRENT : REVISION+1 : AGE
augmented the interface (new functions) CURRENT+1 : 0 : AGE+1
broken old interface (e.g. removed functions) CURRENT+1 : 0 : 0
Therefore a possible history of your lib might be:
1:0:0 start
1:1:0 bug fix
1:2:0 bug fix
2:0:1 new function
2:1:1 bug fix
2:2:1 bug fix
3:0:0 broke api
3:1:0 bug fix
4:1:1 bug fix
5:0:0 broke api
You might, for instance, call the older and newer versions of libodbc.so.x.y.z, according to your needs. Just an idea.
Is there any python library to generate ean128 barcode. I tried 'python-barcode' , but in that library there is no option for ean128.
The person who originally asked this question may not benefit from this, but this is for those who are still looking for an answer.
Note: Code-128 is not same as GS1-128
I was also stuck with this issue a few days ago, and I finally managed to find a python library which supports the GS1-128(UCC/EAN-128) barcode.
The library I am referring to is called "treepoem". Strange name I agree that's what makes it so hard to find. It is a wrapper for BWIPP library. And it has a dependency on ghostscript as well. About the name; Barcode -> Bark ode -> Tree poem.
Important links:
1) Ghostscript; download and install it and also add its "bin" and "lib" folder to
system's path variable.
https://www.ghostscript.com/download/gsdnld.html
2)treepoem
https://pypi.org/project/treepoem/
3) All-codes; here in the repository you will find all supported barcodes here.
https://github.com/adamchainz/treepoem/blob/master/treepoem/data.py
import treepoem
image = treepoem.generate_barcode(
barcode_type='gs1-128', # One of the BWIPP supported codes.
data='(01)14-digit-product-code')
image.convert('1').save('barcode.png')
I think that EAN 128 is the same thing as Code 128 (https://en.wikipedia.org/wiki/Code_128). It seems to be supported by python-barcode
There is an alternative lib with code 128
I'm trying to link my XPCOM extension against the 1.9.3a3pre SDK and I get the following:
error LNK2001: unresolved external symbol _moz_xmalloc
So, what lib do I need to link to? The documentation doesn't say.
This is on Windows right now, but I'll need it to build on Mac and Linux (32bit/64bit) as well.
Edit: Now with bounty.
Edit: Update: Turns out FF3.7 was cancelled. So I don't have to worry about this until FF4.
I have same error, and linking to mozalloc helps for that.
define 'XPCOM_GLUE' in C++ Preprocessor Definition property. It will fix the linking error.
Try defining MOZ_NO_MOZALLOC when compiling your extension, you will then get a DLL that uses your CRT's allocators. (Don't forget to use the NS_* allocators for XPCOM-compatible memory.)
Add MOZ_NO_MOZALLOC in C++->Preprocessor->Definition property.
Use xpcomglue_s_nomozalloc.lib instead of xpcomglue_s.lib in Linker->Input->Additional Dependencies
It will be OK!
reminder note: another option that can cause this even though everything else seems to be configured correctly in the project, is pointing at the wrong libs folder - such as 32 bit version for a 64 bit build.
edit v40 mozalloc.lib has changed name to mozglue.lib and has some additional methods.
edit v41 mozglue.lib has changed name to mozcrt.lib
I am using the POSIX call nftw() for traversing a directory structure. The directory structure is flat - only 4 files and no subdirectories.
However when I call nftw() a lot of times on this flat directory then I get an error message after a while:
"too many open file handles".
It turned out that this happens when the flag FTW_CHDIR is used.
Would you agree that it is a bug in the Linux implementation of nftw() ?
UPDATE
A fix is now available in the glibc repositories.
here are some links to the source code I have used for testing:
main.cpp: http://sourceware.org/bugzilla/attachment.cgi?id=4586&action=view
Makefile: http://sourceware.org/bugzilla/attachment.cgi?id=4587&action=view
UPDATE
MacOS-X is also hit by the bug
Solaris9, Solaris10 and AIX 5.3 do not have the bug
For me it looks like there is really something wrong with the nftw implementation on linux.
I have filed a bug report, see here
UPDATE: A fix is available in the glibc repositories now.
It has the same behaviour on Mac OS 10.6.2. So probably somehow part of the specification, though I don't see how exactly.
Regarding Mac OS: bugreport submitted to Apple as radar #7640283. (No hyperlink possible, unfortunately.)