Comments (34)
Hmm, I looks like it doesn't like when both the --version
flag and a file is specified.
from dstep.
I tagged a new version as well, v0.2.2
. I think you should be able to try the new version with dub fetch dstep && dub run dstep
. This will of course compile DStep.
from dstep.
On Debian Sid, you have to install libclang-3.7-dev and libbz2-dev, yet the build still fails to find -lclang. I am guessing it is not looking in the 3.7 directories, which means the search path is wrong. Debian Sid still defaults to 3.6 and I have not installed the default dev packages, because I want to force 3.7 usage.
|> dub run dstep -- --version
Building package dstep in /home/users/russel/.dub/packages/dstep-0.2.2/
Performing "debug" build using dmd for x86_64.
tango 1.0.3+2.068: target for configuration "static" is up to date.
mambo 0.0.7: target for configuration "library" is up to date.
dstack 0.0.5: target for configuration "library" is up to date.
dstep 0.2.2: building configuration "default"...
.dub/packages/mambo-0.0.7/mambo/util/Traits.d(154,39): Deprecation: typedef is removed
.dub/packages/mambo-0.0.7/mambo/util/Traits.d(182,30): Deprecation: typedef is removed
Linking...
/usr/bin/ld: cannot find -lclang
collect2: error: ld returned 1 exit status
--- errorlevel 1
dmd failed with exit code 1.
from dstep.
On Fedora Rawhide, libclang and libbz2 dependency problems seems solved by having the clang-libs and bzip2-libs packages installed. However, there seems to be a problem in the latest DMD beta release. I am using 2.069 on Sid but 2.070-b1 on Rawhide.
|> dub run dstep -- --version
Building package dstep in /home/russel/.dub/packages/dstep-0.2.2/
Performing "debug" build using dmd for x86_64.
tango 1.0.3+2.068: building configuration "static"...
tango.io.FileScan is deprecated. Please use tango.io.FilePath.toList or tango.io.vfs.* instead.
tango.math.BigInt is deprecated. Please use std.bigint instead.
.dub/packages/tango-1.0.3_2.068/tango/text/xml/SaxParser.d(808,8): Error: class tango.text.xml.SaxParser.SAXException use of object.Throwable.message() is hidden by SAXException; use 'alias message = Throwable.message;' to introduce base class overload set
dmd failed with exit code 1.
from dstep.
It needs to be able to find libclang. Either it in same directory as DStep or in the standard search paths. I should be the same as any other application. It's quite difficult to take in to considerations all different versions of Linux and their different locations of placing libraries.
from dstep.
About the beta, it's a known issue [1]. I think it's fixed by this [2].
[1] https://issues.dlang.org/show_bug.cgi?id=15555
[2] dlang/druntime@80e5059
from dstep.
I could look into linking statically with libclang. I could also set up a docker environment, that would allow me to build for more platforms.
from dstep.
I think the issue is one of allowing the "compiler" to know which CLang to work with. Different Linux distributions have different places to store things.
from dstep.
Yes, but /usr/lib
and /usr/local/lib
are standard Posix library search paths.
from dstep.
Indeed, but with Debian they only get populated by the default package if they support multiple versions, as with LLVM and Clang. Whilst Fedora also have a system for distinguishing variants, for LLVM and Clang they only have one. The issue here is to easily enable people to add to the LD_LIBRARY_PATH for the Dub build. From LDC build experience LLVM has a tool for setting all the paths, you just have to point to the version you want.
from dstep.
The issue here is to easily enable people to add to the LD_LIBRARY_PATH for the Dub build
Wouldn't LD_LIBRARY_PATH=... dub
work? Or do you have something else in mind?
From LDC build experience LLVM has a tool for setting all the paths, you just have to point to the version you want
I tried that, didn't work. It didn't read the environment variable for the config binary. But that should hopefully not be needed since in this cases there's only one file that it needs to find, libclang.so.
from dstep.
I'll try the LD_LIBRARY_PATH thing now. Given then context this is probably the easiest way out.
from dstep.
Sadly not :-(
|> find /usr -iname libclang.so
find: β/usr/share/doc/google-chrome-stableβ: Permission denied
/usr/lib/llvm-3.7/lib/libclang.so
519 anglides:~
|> LD_LIBRARY_PATH=/usr/lib/llvm-3.7/lib dub run dstep -- --version
Building package dstep in /home/users/russel/.dub/packages/dstep-0.2.2/
Performing "debug" build using dmd for x86_64.
tango 1.0.3+2.068: target for configuration "static" is up to date.
mambo 0.0.7: target for configuration "library" is up to date.
dstack 0.0.5: target for configuration "library" is up to date.
dstep 0.2.2: building configuration "default"...
.dub/packages/mambo-0.0.7/mambo/util/Traits.d(154,39): Deprecation: typedef is removed
.dub/packages/mambo-0.0.7/mambo/util/Traits.d(182,30): Deprecation: typedef is removed
Linking...
/usr/bin/ld: cannot find -lclang
collect2: error: ld returned 1 exit status
--- errorlevel 1
dmd failed with exit code 1.
from dstep.
Do you have a symlink libclang.so
pointing to libclang.so.1
or whatever that actual library is called?
from dstep.
Yes. It is created when installing the libclang-.*-dev package:
|> ll /usr/lib/llvm-3.7/lib/libclang.so
lrwxrwxrwx 1 root root 40 Dec 10 14:17 /usr/lib/llvm-3.7/lib/libclang.so -> ../../x86_64-linux-gnu/libclang-3.7.so.1
from dstep.
Hmm, it looks liked Dub doesn't forward the environment variables. If I invoke DMD directly it works. But it still requires to use LD_LIBRARY_PATH
at runtime.
from dstep.
I suppose I could relent and just install the Debian default (which is currently 3.6).
from dstep.
No, that doesn't work. From what I can see Debian install no LLVM related libraries directly in /usr/lib or /lib. LLVM related things are all siloed in /usr/lib/llvm--.
from dstep.
π
from dstep.
It appears that Fedora ensure they put an entry for LLVM in a file in ld.so.conf.d so the LLVM libs are in the search path. From what I can tell, Debian do not do this. Fedora allows for multiple LLVMs, so they are siloed, but it is only the most recent and then any past ones applications need. Debian have many, many LLVMs available, but leave it entirely up to clang to sort of dynamic link paths.
from dstep.
I'm available on IRC, perhaps easier to discuss there.
from dstep.
Until Dub passes LD_LIBRARY_PATH I am not sure there is any solution to building DStep on Debian using Dub. Sad, butβ¦
from dstep.
I've tried a lots of different combinations of environment variables, but none of them seem to work. The only thing that works is to modify dub.json
. Change the -L
and -rpath
flags in the lflags-posix
attribute.
from dstep.
This is seemingly to get worse :-( I have downgraded DMD to 2.069.2 on Fedora. libclang.so is in the path, but libbz2.so is not:
|> ldconfig -v | grep clang
ldconfig: Can't stat /libx32: No such file or directory
ldconfig: Path /usr/lib' given more than once ldconfig: Path
/usr/lib64' given more than once
ldconfig: Can't stat /usr/libx32: No such file or directory
libclang.so -> libclang.so
|> ldconfig -v | grep bz2
ldconfig: Can't stat /libx32: No such file or directory
ldconfig: Path /usr/lib' given more than once ldconfig: Path
/usr/lib64' given more than once
ldconfig: Can't stat /usr/libx32: No such file or directory
libbz2.so.1 -> libbz2.so.1.0.6
libbz2.so.1 -> libbz2.so.1.0.6
|> dub run dstep -- --version
Building package dstep in /home/russel/.dub/packages/dstep-0.2.2/
Performing "debug" build using dmd for x86_64.
tango 1.0.3+2.068: building configuration "static"...
tango.io.FileScan is deprecated. Please use tango.io.FilePath.toList or tango.io.vfs.* instead.
tango.math.BigInt is deprecated. Please use std.bigint instead.
mambo 0.0.7: building configuration "library"...
.dub/packages/mambo-0.0.7/mambo/serialization/Serializer.d(718,30): Deprecation: typedef is removed
.dub/packages/mambo-0.0.7/mambo/util/Traits.d(154,39): Deprecation: typedef is removed
.dub/packages/mambo-0.0.7/mambo/util/Traits.d(182,30): Deprecation: typedef is removed
dstack 0.0.5: building configuration "library"...
.dub/packages/mambo-0.0.7/mambo/util/Traits.d(154,39): Deprecation: typedef is removed
.dub/packages/mambo-0.0.7/mambo/util/Traits.d(182,30): Deprecation: typedef is removed
dstep 0.2.2: building configuration "default"...
.dub/packages/mambo-0.0.7/mambo/util/Traits.d(154,39): Deprecation: typedef is removed
.dub/packages/mambo-0.0.7/mambo/util/Traits.d(182,30): Deprecation: typedef is removed
Linking...
/usr/bin/ld: cannot find -lclang
/usr/bin/ld: cannot find -lbz2
collect2: error: ld returned 1 exit status
from dstep.
I don't know what to tell you. libbz2 is a very standard/basic library. If it cannot find that it seems almost broken. Where does Fedora place its libraries?
from dstep.
That was my fault, I forgot to install bzip2-devel. Silly me. Only the -lclang is a real problem, and I do not understand than on Fedora as libclang.so is in the search path.
from dstep.
Creating a symlink in /usr/lib
or /usr/local/lib
should work. BTW, is the library the correct architecture?
from dstep.
My current hypothesis is that dmd is driving the linker in such a way as it does not use the ld.so search path.
I will do that just to show it working, but I do not touch /usr/lib or /usr/local/lib manually, that is package territory.
All libraries are x86_64 here.
I manually hacked the final dmd command adding the path and:
dmd -of.dub/packages/dstep-0.2.2/.dub/build/default-debug-linux.posix-x86_64-dmd_2069-FD00298C00987FC76518B1B95E49DF2E/dstep .dub/packages/dstep-0.2.2/.dub/build/default-debug-linux.posix-x86_64-dmd_2069-FD00298C00987FC76518B1B95E49DF2E/dstep.o .dub/packages/dstack-0.0.5/libdstack.a .dub/packages/mambo-0.0.7/libmambo.a .dub/packages/tango-1.0.3_2.068/libtango.a -L--no-as-needed -L-rpath -L. -L-L. -L-L/usr/lib64/llvm -L-lclang -L-lbz2 -g
which works fine. So I think we can conclude it is dmd that is the culprit here.
from dstep.
You can add -L-L/usr/lib64/llvm
to dub.json
to avoid manually invoking DMD. You can also append -v
to the DMD command to see the linker command it uses.
Is the ld.so search path the same as LD_LIBRARY_PATH?
from dstep.
dstep --help still shows 0.2.1.
LD_LIBRARY_PATH adds to the path that ld.so is the manager of. I now need to work out how dmd can invoke ld without ld.so path being in play. This cannot be.
The next real problem though is how to get commands built with Dub into $PATH without being very, very silly.
from dstep.
dstep --help still shows 0.2.1.
Looks like I forgot to update that.
LD_LIBRARY_PATH adds to the path that ld.so is the manager of. I now need to work out how dmd can invoke ld without ld.so path being in play. This cannot be.
DMD invokes the C compiler to do the linking. You can see that by adding the -v
flag when invoking DMD.
from dstep.
I had a play with this and gcc is the problem, not dmd. Well not per se. It could yet be an option dmd puts out.
I have put out a query with someone who works on GCC on Fedora/RHEL.
from dstep.
I was wrong, ld doesn't use the ldconfig path, only the runtime loader does. This means LLVM shared object location has to be manually specified on both Debian and Fedora. Having to manually edit dstep.json or dstep.sdl in the repository checkout cannot be the solution, just a temporary hack.
So gcc and dmd are working as they should. The problem thus rests with Dub and it needing to provide platform specific settings. Which actually it does, well in the SDL it does, not sure about JSON.
This means it is up to the original DStep source to have all the variants, which means collecting pull requests from volunteers like me. I'll see what I can do tomorrow on this.
from dstep.
Just to note that 2.070-b2 fixes the problem noted earlier regarding 2.070-b1.
from dstep.
Related Issues (20)
- Pointer arithmetic and parentheses elision
- Dstep + bindbc HOT 1
- `--normalize-modules` insert underscore in the module decl but not in the filename
- typedef function prototypes don't retain arguments HOT 5
- dub run failure - ld cannot find @linker_flags.txt HOT 4
- doc error:
- Missing import HOT 2
- Unhandled type kind objCTypeParam HOT 2
- const T arr[] gets converted to imcompatible const(T) *arr instead of a warning HOT 2
- Improper output when importing core.stdc.limits HOT 1
- Rename enum members can create invalid enum names HOT 1
- API macro erased but should be extern(System) HOT 2
- /usr/include/cuda_runtime_api.h ==> d: Error: undefined identifier `cudaError_t` HOT 6
- Assertion Failure when defining a cast from int to function pointer
- Unhandled type kind objCObject when trying to bind Foundation.framework on macOS
- enh? add enum alias (as dpp do) HOT 1
- unknown type name 'size_t' HOT 1
- `--alias-enum-members=true` shouldn't affect global anonymous enums
- Unnecessary leading dot in alias
- Add support for adding public imports
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dstep.