This SO thread Why does glibc “timezone” global not agree with system time on DST? is not a solution for my problem.
My system has glibc 2.11.3 and for my project I compiled glibc 2.22. I ran make localedata/install-locales.
This MCVE displays the correct time only when linked against the old glibc version. Linking it against the new glibc version it displays the UTC time:
#include <time.h>
#include <stdio.h>
int main()
{
struct tm * tmNow;
time_t dtNow;
char sBuffer [100];
tzset();
time( &dtNow );
tmNow = localtime( &dtNow );
strftime( sBuffer, sizeof(sBuffer), "%Y-%m-%d %T", tmNow );
printf("%ld - %s\n", timezone, sBuffer);
}
When I try to run tzselect in the bin/ directory of the new glibc version I get this error:
./tzselect: line 171: /usr/glibc/share/zoneinfo/iso3166.tab: No such file or directory
./tzselect: time zone files are not set up correctly
More or less it says all but for the moment I am not capable to find out how to set up the file /usr/glibc/share/zoneinfo/iso3166.tab.
How do I set up the timezone for the new glibc version permanently?
I do not want to use the TZ variable!
UPDATE:
Using the TZ variable does not change anything. I guess I did not configure correctly the new glibc version.
UPDATE: Copying the existing /usr/share/zoneinfo system directory into the new /usr/glibc/share/zoneinfo directory at least fixed the problem with the TZ variable. But as long the TZ variable is not set the new glibc version does not recognize the correct timezone.
I opened the new libc.so.6 library with vi and searched for localtime.
The hard coded directory where the new glibc version was looking for localtime is set to /usr/glibc/etc.
Then it was an easy task: I ran the command
ln -s /usr/share/zoneinfo/Europe/Vienna /usr/glibc/etc/localtime
and now the localtime is recognized correctly in the new glibc version without using the TZ variable.
Related
I have a project using Python 3.10.4, i. e., the Pipfile has,
[requires]
python_version = "3.10.4"
I installed Python 3.10.4 using pyenv install 3.10.4 and now pyenv versions returns,
* system (set by /home/username/.config/pyenv/version)
3.10.4
Now when I run pipenv install I get,
Creating a virtualenv for this project…
Using /home/username/.config/pyenv/versions/3.10.4/bin/python3 (3.10.4) to create virtualenv…
⠋created virtual environment CPython3.10.4.final.0-64 in 82ms
creator CPython3Posix(dest=/home/username/.local/share/virtualenvs/project-2ZeatEXR, clear=False, no_vcs_ignore=False, global=False)
seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/home/username/.local/share/virtualenv)
added seed packages: pip==20.3.4, pkg_resources==0.0.0, setuptools==44.1.1, wheel==0.34.2
activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator
Virtualenv location: /home/username/.local/share/virtualenvs/project-2ZeatEXR
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
from . import utils
File "/usr/lib/python3/dist-packages/pipenv/vendor/requests/utils.py", line 27, in <module>
from .cookies import RequestsCookieJar, cookiejar_from_dict
File "/usr/lib/python3/dist-packages/pipenv/vendor/requests/cookies.py", line 172, in <module>
class RequestsCookieJar(cookielib.CookieJar, collections.MutableMapping):
AttributeError: module 'collections' has no attribute 'MutableMapping'
The line Using /home/username/.config/pyenv/versions/3.10.4/bin/python3 (3.10.4) indicates that pipenv has found the right Python version and is using it to create the virtual environment but then when creating the lock file, observe that it uses the lib: /usr/lib/python3/dist-packages/pipenv/vendor/requests/utils.py directory is of the system installation. Which then causes the error since the system's lib is for Python 3.9.
Maybe this is a bug or maybe I have missed some config. Could someone see what is going wrong here?
I'm converting an old OCX project to QMake (as it's getting the "new" standard in my company).
In my Button.pro file, I add the MIDL compiler by the means of
idl_c.output = $${DESTDIR}/${QMAKE_FILE_BASE}.tlb
idl_c.input = IDL
idl_c.commands = $${QMAKE_IDL} ${QMAKE_FILE_IN} $${IDLFLAGS} \
/tlb ${QMAKE_FILE_OUT}
idl_c.variable_out = GENERATED_FILES
idl_c.CONFIG += target_predeps
idl_c.name = MIDL
QMAKE_EXTRA_COMPILERS += idl_c
IDL += $$PWD/Button.odl
The .pro file also mentions that I have a RC file
RC_FILE += $$PWD/Button.rc
This RC file contains a TYPELIB for this tlb file, meaning that it has to be available before rc.exe runs
1 TYPELIB "Button.tlb"
I then generate a makefile through QMake and build my project using nmake. Everything runs fine: the console shows no error and the output OCX is generated (and works). I can clearly see that MIDL is executed first, the RC, then the rest.
If I try to build using jom, the order is not satisfied anymore. jom seems to try to execute MIDL and RC in parallel: Button.tlb is then not yet existing at the time RC.exe needs it and the build fails.
Is there a way to force jom to wait for midl to be done before starting rc?
I'm using QT 5.3.1 under MSVC2013.
QMake is nothing more than a makefile generator. And your issue is due to make (or jom) parallel job execution. To fix this you only have to induce a single dependency (w/o any recipe) in a Makefile between res/obj and tlb files. This could be done with:
dep_restlb.target = $(RES_FILE)
dep_restlb.depends = $${DESTDIR}/Button.tlb # QMAKE_FILE_BASE is not available here
QMAKE_EXTRA_TARGETS += dep_restlb
I am the developer of this small library: https://github.com/martin-damien/babel and I have a problem with Luarocks releases.
From source
When I install from source with Luarocks I have no problem:
$ luarocks make --local rockspecs/babel-1.2-2.rockspec
From internet
But when deployed (using: tag master, add new rockspec release and publish to Luarocks), I can't install using
$ luarocks install --local babel
Because I encounter the following error:
Installing https://luarocks.org/babel-1.2-2.src.rock...
Using https://luarocks.org/babel-1.2-2.src.rock... switching to 'build' > mode
stat: malsukcesis eltrovi statinformon pri «locales/zh-HK.lua»: No such > file or directory
Error: Build error: Failed installing locales/zh-HK.lua in /home/damien/.luarocks/lib/luarocks/rocks/babel/1.2-2/lua/locales/zh-HK.lua: locales/zh-HK.lua: No such file or directory
As you can see in https://github.com/martin-damien/babel/issues/14 the error occure on different files (but until now, only with locale files, not with the babel.lua file).
I have no idea why it randomly crash like this, so if someone know why or have an idea from where it could come from...
Thanks in advance,
Damien
The location of the files in the build.modules table is (from the docs on the rockspec format):
relative to source.dir
Where source.dir is
source.dir (string) - the name of the directory created when the source archive is unpacked. Can be omitted if it can be inferred from the source.file field. Example: "luasocket-2.0.1"
and source.file is
source.file (string) - the filename of the source archive. Can be omitted if it can be inferred from the source.url field. Example: "luasocket-2.0.1.tar.gz"
You don't specify source.dir or source.file in your rockspec but you do set source.url (because you have to).
So you have source.url = https://github.com/martin-damien/babel/archive/v1.2-2.zip which (presumably) ends up with source.file = v1.2-2.zip and then source.dir = v1.2-2 but your zip file extracts into a babel-1.2 so luarocks can't find your source files. (The screenshot in the linked issue seems to indicate that luarocks uses source.file = v1.2.zip and the archive extracts to babel-1.2 but I'm not sure how that's possible.)
Add dir = "babel-1.2" to your rockspec's source table an I expect it will work.
I am new to linux device driver development. I am trying to write a simple hello world module that would display the version of kernel running on the system where I try to insert hello_world module into kernel.
I used LINUX_VERSION_CODE in version.h to get linux version and built the module.
When I try to insert the ko file on a different system other than where it was built, it still shows the version of kernel where it was built
I believe issue lies with using C macro.
Can someone help me how to find linux version of local machine where the ko is to be inserted instead of finding version of kernel where my module gets built
You're right - LINUX_VERSION_CODE is a macro that provides compile-time info about the version of the Linux headers that you're using to compile the module. The macro cannot have any knowledge about the version of the kernel that the module will actually be loaded into.
The utsname() function in <linux/utsname.h> provides a pointer to a new_utsname struct, which has sysname, release and version members that contain what you're looking for.
The information from these members is used in /proc/version, as shown in fs/proc/version.c :
static int version_proc_show(struct seq_file *m, void *v)
{
seq_printf(m, linux_proc_banner,
utsname()->sysname,
utsname()->release,
utsname()->version);
return 0;
}
linux_proc_banner is a string that is currently defined as follows :
const char linux_proc_banner[] =
"%s version %s"
" (" LINUX_COMPILE_BY "#" LINUX_COMPILE_HOST ")"
" (" LINUX_COMPILER ") %s\n";
On my system, reading /proc/version - and thus reading these members - results in obtaining the following string :
Linux version 4.1.6-1-ARCH (builduser#tobias) (gcc version 5.2.0 (GCC) ) #1 SMP PREEMPT Mon Aug 17 08:52:28 CEST 2015
Thus, sysname is Linux, release is 4.1.6-1-ARCH, and version is #1 SMP PREEMPT Mon Aug 17 08:52:28 CEST 2015.
I downloaded the source of LuaJIT and compiled it with msvc120.dll (VS 2013 x64). When I run it from the command line I have no problems executing some basic lua. Now the LuaJIT installation guide mentions moving luajit.exe and lua51.dll into their own folder. From there it says to create a lua folder and under that a jit folder with the contents of src/jit moved underneath the newly created jit folder.
From my understanding my folder should look like and contain:
luajit.exe
lua51.dll
/lua
/jit
bc.lua
[rest of jit files]
vmdef.lua
Is this correct or am I missing files?
Now after I built my luajit I tried to wire it up into my luarocks to act as my interpreter using
install.bat /LUA C:\LuaJIT\2.0.3\[folder with above content]
However this cannot find the header files. I then copied over what are the header files into the folder above and that wires it up, but I can never actually get anything to compile when pointed over to LuaJIT. Edit: The error I get is the following,
C:\LuaJIT\2.0.3\bin\lua51.dll : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2D0
Error: Failed installing dependency: https://rocks.moonscript.org/luafilesystem-1.6.2-2.src.rock - Build error: Failed compiling module lfs.dll
Is the correct way to handle this to simply point to my lua binaries and from there leverage LuaJIT to run my files or am I doing something wrong with wiring up LuaJIT and luarocks? The former seems to work for the most part, since I only ran into one library compilation issue, lua-cjson.
I've run on exactly the same problem, but they've found a solution right here:
https://github.com/keplerproject/luafilesystem/issues/22
I knew that for "linking DLLs statically" there is a so-called "export" .lib file, which is passed to the linker (and not the DLL itself).
So, for example, when compiling, LuaRocks was doing this:
cl /nologo /MD /O2 -c -Fosrc/mime.obj -ID:/LuaJIT-2.0.4/include/ src/mime.c -DLUA_COMPAT_APIINTCASTS -DLUASOCKET_DEBUG -DNDEBUG -DLUASOCKET_API=__declspec(dllexport) -DMIME_API=__declspec(dllexport) mime.c
link -dll -def:core.def -out:mime/core.dll D:/LuaJIT-2.0.4/bin/lua51.dll src/mime.obj
My LuaJIT was compiled from source in D:\LuaJIT-2.0.4\src, but I made two folders myself: D:\LuaJIT-2.0.4\include with all *.h files copied from src and D:\LuaJIT-2.0.4\bin with luajit.exe, lua51.dll, and then later lua51.exp and lua51.lib. Still same error, but this was the right track.
Fix
Now, check where your LuaRocks configs are:
luarocks.bat help
Scroll down to a section like:
CONFIGURATION
Lua version: 5.1
Configuration files:
System: D:/luarocks/config-5.1.lua (ok)
User : (... snip ...)
Edit the System configuration file, specifically see the part:
variables = {
MSVCRT = 'VCRUNTIME140',
LUALIB = 'lua51.dll'
}
Here! LUALIB should be the .lib file. If your export lib is alongside the DLL, you just need to change to:
variables = {
MSVCRT = 'VCRUNTIME140',
LUALIB = 'lua51.lib' -- here!
}
Verification
And now:
luarocks.bat install luasocket
(...)
link -dll -def:core.def -out:socket/core.dll D:/LuaJIT-2.0.4/bin/lua51.lib src/luasocket.obj (...)
(...)
luasocket 3.0rc1-2 is now built and installed in D:\luarocks\systree (license: MIT)
Note the first argument passed to the linker.