When I try to execute something similar to this line below:
tlib.exe /C mylib.lib
+-obj\Release\lib-10\src\object\objectFile.obj
I get this output:
TLIB 6.2 Copyright (c) 1987-2010 Embarcadero Technologies, Inc.
Warning: '.\obj\Release\objectFile.obj' not found in library
If I remove the "lib-10" manually and put the objectFile.obj at the "obj\Release\src\object\" dir it works fine.
What can I do?
At the website there are no useful information about this. If there is no workaroud I will try this manual solution. Just to clarify: tlib.exe is my only choice.
Thanks
Recent versions of Tlib will handle properly quoted paths with -/+ on the command line, but older versions do not. If the IDE or your shell isn't properly quoting these paths, your best bet is to use a different path.
I would discourage use of paths containing those characters. I know it's a remnant of times past, but many console applications grew out of those legacy times and still have the old constraints.
Related
SO!
Let's say I have a number of settings (GCC compiler 9.3.0 built from source, as the distribution I have to use has a very old one, along with environment setup) for a new Kit in QtCreator.
I have managed to setup an environment for compilation and execution of compiled binaries, and made a script to make it work (like qmake -nocache -recursive/make/sudo make install, direct execution of g++, and other stuff).
One thing that script can't do at the moment, is that it cannot create a kit for QtCreator with new compilers and environment being set as required, so after running a script, its user has to go through setting it up himself through GUI, which is bad, because this can cause misconfiguration.
This thing I'm trying to create is going to be used by around ~200 people in my company, so leaving readme.txt with instructions just doesn't go well enough for me - I don't want running around fixing missing "{" and "}" in Environment description in created Kits, and other stuff.
Are there ways to create Kits for QtCreator automatically from command line? Maybe, there's some files to edit?
I've looked into this one a few years back (I wanted to do something similar for registering Buildroot toolchains automatically in QtCreator), and I was unable to find an off the shelf solution. So i think there are 2 ways to implement this:
a) Implementing a command line utility the manipulate the ~/.config/QtProject/qtcreator/{toolchains,profiles}.xml files. Maybe by (re)using the existing C++ implementation within QtCreator, or just re-implement it ie. in Python. Back than I didn't start to work on this as there was no real business need.
b) Switching to qbs, as qbs has support for setting up toolchains from the command line ( see: https://doc.qt.io/qbs/cli-setup-toolchains.html)
If you decide to go with solution a), please let me know and maybe we can partner up to implement it.
Check out the command line sdktool bundled with QtCreator:
The SDK tool can be used to set up Qt versions, tool chains, devices
and kits in Qt Creator.
There still is a lot of knowledge about Qt Creator internals required
to use this tool!
I haven't tried it yet, but I did find the executable under Tools/QtCreator/libexec/qtcreator subdirectory of the Qt Creator installation directory. ./sdktool --help works for me under Linux.
I want to various projects for various platforms, and as such I've concluded that the easiest way to to this is probably going to just have buildroot create the toolchain and then alter the environment to use said toolchain.
From section 8.14.1 of the buildroot manual:
For your convenience, by selecting the option
BR2_PACKAGE_HOST_ENVIRONMENT_SETUP, you can get setup-environment
script installed in output/host/and therefore in your SDK. This script
can be sourced with . your/sdk/path/environment-setup to export a
number of environment variables that will help cross-compile your
projects using the Buildroot SDK: the PATH will contain the SDK
binaries, standard autotools variables will be defined with the
appropriate values, and CONFIGURE_FLAGS will contain basic ./configure
options to cross-compile autotools projects. It also provides some
useful commands. Note however that once this script is sourced, the
environment is setup only for cross-compilation, and no longer for
native compilation.
Alright, that sounds pretty much like exactly what I want. However, I have not figured out how to set BR2_PACKAGE_HOST_ENVIRONMENT_SETUP. I found no mention of anything similar when looking through make menuconfig, I tried to grep the entire buildroot source tree for that string with no luck, and simply exporting it as an environment variabl did not produce a different result either. So, how do I set BR2_PACKAGE_HOST_ENVIRONMENT_SETUP, exactly?
I just stumbled across the same problem. The option was submitted in April 2020, so buildroot-2020.02.8 (the long term support version as of writing) doesn't support it, whereas the PDF available online is newer -- I suspect you are using the same version; the buildroot download page presents the longer term support version first.
In menu-config, you do a search ("/") of HOST_ENVIRONMENT and then you find your answer:
screenshot
My goal is to connect the open-source CBC solver with Pyomo in Spyder. I am working on a Windows 10 machine and it is not an option for me to use the NEOS server due to company policy.
I have downloaded the binaries from Bintray (https://bintray.com/coin-or/download/Cbc#files) that include a cbc.exe file. However when trying to run it, several errors come up stating that I am missing files (among other libbz2-1.dll and zlib1.dll). I do not know much about linux or software development but after a lot of time on google I understand that these are used for unpacking data among other things. I found all files except zlib1.dll in a developer chat on the same subject and zlib1.dll I found on another page. However when running I now get the error: “The application was unable to start correctly (0xc000007b).
I have also tried downloading MSYS2 MinGW and followed instructions from CBC. I don’t know if I require this or if it is only for developers.
Can anyone tell me what to do? I suspect other people than myself want to use CBC in Pyomo as an alternative to GLPK.
If you already have the .exe file, make sure it is in your current working folder (set as the working directory in Spyder, simply opening your file is not enough) and call it using the SolveFactory function:
opt = SolverFactory("cbc.exe")
results = opt.solve(model)
It works for me.
You will find some general information here where i outlined some approaches.
While this was targeted at Clp, it also applies to Cbc.
It's a bit strange as i observed too, that some libs are not statically linked (zlib) while it's certainly doable. But as mentioned in the thread, this should not be the case anymore (see the restriction about which files are fully statically linked) and therefore your observation is strange (and you did not say, which file you downloaded).
So i would trying one of the following (in this order):
Try again with your source, but stick to the master-versions (see first link) as the maintainer only guaranteed fully-static builds for those!
Use the builds from AMPL
(tested and works for me; generally recommended in terms of quality/stability of builds)
Use the builds from coin-or/pulp, another modelling-tool for python
(tested and works for me)
Compile from source using mingw64
(Use any build and provide some external dll of zlib and co -> hard to debug)
Of course i completely ignored other potential issues:
license-stuff (what's part of those builds)
not sure if a company can afford to use binaries not build themself in regards to legal stuff
version-compatibility with python
does every version of Cbc work
cbc version + configuration
modern version
compiled with multi-threading
...
I have to create (or rather modify) software package for MacOSX on Windows. I can do what I need with .pax files, so the only thing left is bill-of-material.
Does anyone know of a library that can do it? Is there BOM file format (Apple-version) available?
TIA
There is now an open source version of mkbom which also compiles for windows at:
http://hogliux.github.io/bomutils/
The windows version still contains some bugs (no special characters in file names and limitations on file path length). However, it should work for simple installers.
The website also has an easy to follow step-by-step tutorial on how to create a Mac OS X installer (however, the tutorial is for linux, see http://hogliux.github.io/bomutils/tutorial.html ).
Well, BOM is not necessary, MacOSX package is a simple directory structure with optional elements, BOM being one of them.
I'm porting an application to MacOS X - but the original developer's build system uses NMAKE, and ideally they'd like to keep it instead of switching to a new one.
I've managed to get NMAKE running under OSX using wine (built using MacPorts) and added Objective C support to the build files, and created a Unix-linked PE wrapper 'run.exe' which wine can load but uses POSIX to call back into things like gcc and ld, as is described on various places online as a means of escaping out of wine back into Unix.
However, I'm having a few specific issues. They're minor enough that I can get on with the port, but it does mean I need to run builds a few times sometimes, because of timing.
Basically, when wine.exe calls back into the shell and thus gcc, the link between child processes seems to be broken. gcc and ld will never return an error code even on failure, because they can't get the exit code from their spawned children. ar will actually print out it can't find its child and return immediately, causing problems when ld tries to link object files to libraries that are still being put together.
Has anyone else tried anything similar and seen the same problem, on OSX or elsewhere? Is there an obvious solution?
The Microsoft .NET Rotor (SSCLI) project includes source code, intended to be build on OSX and elsewhere. The Rotor source code includes the source code to NMake. So get Rotor working, then use it's Nmake. Even if you prefer to continue to use your Wine-based Nmake, you could probably learn from Rotor's use of Nmake on Unix, it's use of Gcc, etc.
If there is nothing that odd / inconsistent about the original developers build system, could you write an automatic conversion of their make files back into Unix make, and keep your builds 'native'?
(Builds being fraught enough anyway, without extra complications)