I need to build GLEW from source so I can use it with Mingw in Code::Blocks being Mingw doesn't like to use the one's they compile in VS. I'm using Cygwin and I download the source for GLEW here and unzip it. I then browse to the folder with Cygwin using cd. Then I run
make Makefile
It then gives me these errors.
config/config.guess: line 6: $'\r': command not found
config/config.guess: line 8: $'\r': command not found
config/config.guess: line 26: $'\r': command not found
config/config.guess: line 27: $'\r': command not found
config/config.guess: line 38: $'\r': command not found
config/config.guess: line 40: $'\r': command not found
config/config.guess: line 52: $'\r': command not found
config/config.guess: line 63: $'\r': command not found
config/config.guess: line 66: $'\r': command not found
config/config.guess: line 69: syntax error near unexpected token `$'in\r''
'onfig/config.guess: line 69: ` case $1 in
config/config.guess: line 6: $'\r': command not found
config/config.guess: line 8: $'\r': command not found
config/config.guess: line 26: $'\r': command not found
config/config.guess: line 27: $'\r': command not found
config/config.guess: line 38: $'\r': command not found
config/config.guess: line 40: $'\r': command not found
config/config.guess: line 52: $'\r': command not found
config/config.guess: line 63: $'\r': command not found
config/config.guess: line 66: $'\r': command not found
config/config.guess: line 69: syntax error near unexpected token `$'in\r''
'onfig/config.guess: line 69: ` case $1 in
Makefile:40: *** "Platform '' not supported". Stop.
I've read around and I haven't been able to find much useful on solving this problem yet. If you know a better way I can get GLEW working with Mingw that would also answer my question.
On Windows XP
Using Code::Blocks 10.05
Using Cygwin 1.7.16-1
Using GLEW 1.8.0
UPDATE
Those errors have been fixed using dos2unix on the config.guess file. However, when I run the Makefile now it says there is nothing to be done for it.
Looks very much like config.guess has DOS line endings ("\r\n") but make is expecting Unix line endings ("\n"). I would just run whatever tool on config.guess to convert it to Unix line endings, my cygwin has a tool called dos2unix that will do the trick.
If you just want to code and build under Windows refer to this topic Using GLEW to use OpenGL extensions under Windows
Sorry for the late reply on this, but setting a variable SYSTEM works in cygwin:
$ SYSTEM=cygwin make
Related
On my Windows 10, I installed msys2(include mingw32 and build tool, etc, the version is MINGW32_NT-10.0-19044 WIN-7VUR5T4P2BB 3.3.5-341.x86_64 2022-07-04 21:33 UTC x86_64 Msys) in c:\msys64 and qt creator with embedded mingw in folder C:\Qt\5.15.2\mingw81_32, I think these two mingw32s have different version.
There is a qtquick project which use embedded MinGW 8.1.0 32-bit for C/C++ compiler which are different from the ones in msys2.
Now I want to use freetype-2.10.0 in my project, however I don't know how to install freetype library for my qt project (use qmake), because there is no easy-to-use tool like pacman in msys2. That means I need to download freetype source code and build them using gnu make in qt environment (not in msys2, or it will bring confliction).
In order to compile freetype according to its docs as below:
You need to invoke the `autogen.sh' script in the top-level
directory in order to create the `configure' script for your
platform. Normally, this simply means typing:
sh autogen.sh
In case of problems, you may need to install or upgrade Automake,
Autoconf or Libtool. See README.git in the top-level directory
for more information.
Then I put freetype source code to C:\Qt\5.15.2\mingw81_32\freetype-2.10.0 and open a power shell terminal and input:
sh autogen.sh
there is an error indicating aclocal commmand not found which is part of automake as below. Does that means I need to download automake souce code and compile them again? that is too hard for me.
autogen.sh: line 102: aclocal: command not found
autogen.sh: line 55: test: 1: unary operator expected
autogen.sh: line 59: test: 1: unary operator expected
autogen.sh: line 67: test: 10: unary operator expected
autogen.sh: line 71: test: 10: unary operator expected
autogen.sh: line 102: libtoolize: command not found
autogen.sh: line 55: test: 2: unary operator expected
autogen.sh: line 59: test: 2: unary operator expected
autogen.sh: line 67: test: 2: unary operator expected
autogen.sh: line 71: test: 2: unary operator expected
autogen.sh: line 102: autoconf: command not found
autogen.sh: line 55: test: 2: unary operator expected
autogen.sh: line 59: test: 2: unary operator expected
autogen.sh: line 67: test: 62: unary operator expected
autogen.sh: line 71: test: 62: unary operator expected
generating `configure.ac'
running `aclocal -I . --force'
autogen.sh: line 15: aclocal: command not found
error while running `aclocal -I . --force'
So how to use freetype easily in my project? thanks!
I have mounted my Google Cloud Platform credentials file as a volume in my docker container and I use docker-compose to create the GOOGLE_APPLICATION_CREDENTIALS environment variable from this file. When I go into the docker container, the file is there and it's readable and the contents are correct, however when I inspect the content of the environment variable this is what gets returned:
docker exec -it -u celery container_name sh
/opt/ori $ $GOOGLE_APPLICATION_CREDENTIALS
/opt/ori/application_default_credentials.json: line 2: type:: not found
/opt/ori/application_default_credentials.json: line 3: project_id:: not found
/opt/ori/application_default_credentials.json: line 4: private_key_id:: not found
/opt/ori/application_default_credentials.json: line 5: private_key:: not found
/opt/ori/application_default_credentials.json: line 6: client_email:: not found
/opt/ori/application_default_credentials.json: line 7: client_id:: not found
/opt/ori/application_default_credentials.json: line 8: auth_uri:: not found
/opt/ori/application_default_credentials.json: line 9: token_uri:: not found
/opt/ori/application_default_credentials.json: line 10: auth_provider_x509_cert_url:: not found
/opt/ori/application_default_credentials.json: line 11: client_x509_cert_url:: not found
Obviously it's partially reading the JSON file because it extracts the keys, but why can't it find the values?
This statement /opt/ori $ $GOOGLE_APPLICATION_CREDENTIALS is treating the credentials file as an executable and trying to execute it as a script.
This line /opt/ori/application_default_credentials.json: line 2: type:: not found shows you that the operating system could not find the program type:: to execute.
I'm getting a few warnings and fatal error when I try to build omaha on windows 10 machine.
C:\updater\omaha\omaha>hammer
scons: warning: No installed VCs
File "C:\chromium\upd\swtoolkit\site_scons\site_init.py", line 426, in SiteInitMain
scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly
File "C:\chromium\upd\swtoolkit\site_scons\site_init.py", line 426, in SiteInitMain
scons: Reading SConscript files ...
scons: warning: No installed VCs
File "C:\chromium\upd\swtoolkit\site_scons\site_tools\target_platform_windows.py", line 283, in generate
scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly
File "C:\chromium\upd\swtoolkit\site_scons\site_tools\target_platform_windows.py", line 283, in generate
Using precompiled headers.
Building versions: 1.3.99.0
python C:\chromium\upd\omaha\omaha\tools\proxy_clsid_utils.py
AttributeError: SConsEnvironment instance has no attribute 'WiX':
File "C:\chromium\upd\omaha\omaha\main.scons", line 992:
BuildEnvironments(_environments)
File "C:\chromium\upd\swtoolkit\site_scons\site_init.py", line 276:
e.ExecuteDefer()
File "C:\Python24\Lib\site-packages\scons-1.3.1\SCons\Environment.py", line 224:
return apply(self.method, nargs, kwargs)
File "C:\chromium\upd\swtoolkit\site_scons\site_tools\defer.py", line 171:
func(fenv)
File "C:\chromium\upd\swtoolkit\site_scons\site_init.py", line 203:
exports={'env': ec}, duplicate=0)
File "C:\Python24\Lib\site-packages\scons-1.3.1\SCons\Script\SConscript.py", line 553:
return apply(_SConscript, [self.fs,] + files, subst_kw)
File "C:\Python24\Lib\site-packages\scons-1.3.1\SCons\Script\SConscript.py", line 262:
exec _file_ in call_stack[-1].globals
File "C:\chromium\upd\omaha\omaha\recovery\build.scons", line 104:
env.BuildSConscript('repair_exe')
File "C:\Python24\Lib\site-packages\scons-1.3.1\SCons\Environment.py", line 224:
return apply(self.method, nargs, kwargs)
File "C:\chromium\upd\swtoolkit\site_scons\site_tools\environment_tools.py", line 191:
env.SConscript(script_file, exports={'env': env.Clone()})
File "C:\Python24\Lib\site-packages\scons-1.3.1\SCons\Script\SConscript.py", line 553:
return apply(_SConscript, [self.fs,] + files, subst_kw)
File "C:\Python24\Lib\site-packages\scons-1.3.1\SCons\Script\SConscript.py", line 262:
exec _file_ in call_stack[-1].globals
File "C:\chromium\upd\omaha\omaha\recovery\repair_exe\build.scons", line 37:
env.BuildSConscript(subdir)
File "C:\Python24\Lib\site-packages\scons-1.3.1\SCons\Environment.py", line 224:
return apply(self.method, nargs, kwargs)
File "C:\chromium\upd\swtoolkit\site_scons\site_tools\environment_tools.py", line 191:
env.SConscript(script_file, exports={'env': env.Clone()})
File "C:\Python24\Lib\site-packages\scons-1.3.1\SCons\Script\SConscript.py", line 553:
return apply(_SConscript, [self.fs,] + files, subst_kw)
File "C:\Python24\Lib\site-packages\scons-1.3.1\SCons\Script\SConscript.py", line 262:
exec _file_ in call_stack[-1].globals
File "C:\chromium\upd\omaha\omaha\recovery\repair_exe\msp\build.scons", line 156:
old_msi, new_msi = CreateMsiInstallerFiles(
File "C:\chromium\upd\omaha\omaha\recovery\repair_exe\msp\build.scons", line 60:
old_unsigned_output = old_unsigned_env.WiX(
I spent a lot of time debugging warnings and seems scons 1.3.1 doesn't support visual studio 2015, however google's build
instructions imply opposite. Also it's not fully clear whether the error depends on the warnings. Please help to solve the issue.
I solved the issue, turns out a new version of wix toolset has bin folder with all the utils and official docs and tutorial contains wrong environment variable. By the way the warnings have no impact on build process at all.
So probably there is no point to debug any code in similar situations, just need to check the environment.
When running teaspoon, I'm getting the following errors:
rake teaspoon
Starting the Teaspoon server...
Teaspoon running default suite at http://127.0.0.1:64790/teaspoon/default
sh: line 25: `BASH_FUNC_set_shell_label%%': not a valid identifier
Teaspoon running insight suite at http://127.0.0.1:64790/teaspoon/insight
sh: line 25: `BASH_FUNC_set_shell_label%%': not a valid identifier
Teaspoon running wb5 suite at http://127.0.0.1:64790/teaspoon/wb5
sh: line 25: `BASH_FUNC_set_shell_label%%': not a valid identifier
I haven't yet been able to identify which file's line 25 is the problem.
I'm getting some very unusual behaviour.
I followed these instructions for installing jetty but used the latest version instead (9.1.1v20140108)
I had reason to restart Jetty and found I was getting these errors (logged in as root)
Starting Jetty: FAILED Wed Feb 5 12:35:59 EST 2014
So I spent 30 mins looking for an answer, then for reasons I can't recall, I did service jetty check and it was running (had a pid).
So I tried again with service Jetty stop:
root#erp:/var/log# service jetty stop
/etc/init.d/jetty: line 13: chkconfig:: command not found
/etc/init.d/jetty: line 14: description:: command not found
/etc/init.d/jetty: line 15: processname:: command not found
Stopping Jetty: start-stop-daemon: warning: failed to kill 7817: No such process
1 pids were not killed
No process in pidfile '/var/run/jetty.pid' found running; none killed.
OK
None killed? Ok. Let's check that:
root#erp:/var/log# service jetty check
/etc/init.d/jetty: line 13: chkconfig:: command not found
/etc/init.d/jetty: line 14: description:: command not found
/etc/init.d/jetty: line 15: processname:: command not found
Checking arguments to Jetty:
START_INI = /srv/jetty/start.ini
JETTY_HOME = /srv/jetty
JETTY_BASE = /srv/jetty
JETTY_CONF = /srv/jetty/etc/jetty.conf
JETTY_PID = /var/run/jetty.pid
JETTY_START = /srv/jetty/start.jar
JETTY_LOGS = /srv/jetty/logs
CLASSPATH =
JAVA = /usr/bin/java
JAVA_OPTIONS = -Dsolr.solr.home=/srv/solr -Djetty.state=/srv/jetty/jetty.state -Djetty.logs=/srv/jetty/logs -Djetty.home=/srv/jetty -Djetty.base=/srv/jetty -Djava.io.tmpdir=/tmp
JETTY_ARGS = jetty.port=8085 jetty-logging.xml jetty-started.xml
RUN_CMD = /usr/bin/java -Dsolr.solr.home=/srv/solr -Djetty.state=/srv/jetty/jetty.state -Djetty.logs=/srv/jetty/logs -Djetty.home=/srv/jetty -Djetty.base=/srv/jetty -Djava.io.tmpdir=/tmp -jar /srv/jetty/start.jar jetty.port=8085 jetty-logging.xml jetty-started.xml
No PID? Let's check that:
root#erp:/var/log# service jetty start
/etc/init.d/jetty: line 13: chkconfig:: command not found
/etc/init.d/jetty: line 14: description:: command not found
/etc/init.d/jetty: line 15: processname:: command not found
Starting Jetty: FAILED Wed Feb 5 12:39:43 EST 2014
Ok, is there a PID?
root#erp:/var/log# service jetty check
/etc/init.d/jetty: line 13: chkconfig:: command not found
/etc/init.d/jetty: line 14: description:: command not found
/etc/init.d/jetty: line 15: processname:: command not found
Checking arguments to Jetty:
[edit]
Jetty running pid=7993
Weird. Sure enough, a stop and check will give the same results.
What's going on with the jetty startup script? And why am I getting FAILED errors on start which are incorrect, and fail to remove pid errors on stop which are also incorrect?
I have got a fix for all those who have been using that tutorial to install jetty
nano /etc/init.d/jetty
And change this syntax :
start-log-file="$JETTY_LOGS/start.log"
to
start-log-file="start.log"
It will fix everything in the latest jetty build and make it run like a charm.
Hope I could be of help
Ok, so this was a tricky one that was the result of a recent Java update.
I jumped into the jetty.sh at /etc/init.d/jetty and grabbed out the actually executed line:
$ /usr/bin/java -Dsolr.solr.home=/srv/solr -Djetty.state=/srv/jetty/jetty.state \
-Djetty.logs=/srv/jetty/logs -Djetty.home=/srv/jetty -Djetty.base=/srv/jetty \
-Djava.io.tmpdir=/tmp -jar /srv/jetty/start.jar jetty.port=8085 \
jetty-logging.xml jetty-started.xml
and I got this:
java.io.IOException: Cannot read file: modules/npn/npn-1.7.0_51.mod
at org.eclipse.jetty.start.Modules.registerModule(Modules.java:405)
at org.eclipse.jetty.start.Modules.registerAll(Modules.java:395)
at org.eclipse.jetty.start.Main.processCommandLine(Main.java:561)
at org.eclipse.jetty.start.Main.main(Main.java:102)
Which in turn lead me to this solution on the eclipse dev list:
$ cp /srv/jetty/modules/npn/npn-1.7.0_45.mod /srv/jetty/modules/npn/npn-1.7.0_51.mod
$ chown jetty:jetty /srv/jetty/modules/npn/npn-1.7.0_51.mod
Sure enough, Jetty restarted without hassle.
Try running below command in terminal.
sudo service jetty9 stop
I run Jetty 9.2.10.v201503 on pcDuino v3, Ubuntu 14.04. According to my experience with this relatively slow platform, this message may be reported when Jetty server itself starts longer than internal waiting loop in /etc/init.d/jetty script expects.
After adding “set –x” at the beginning of /etc/init.d/jetty file and running that script I noticed that internal waiting loop is implemented as “for” making 15 steps and periodically checking content of the $JETTY_BASE/jetty.state file.
After waiting additional couple of seconds, Jetty server is up and running ok, no errors/warrnings in log files.