Thanks Troy,
Your guess was correct.
:)
Cheers,
Daniel
On Thu 19Mar15 06:20:22PM, Troy A. Griffitts wrote:
> Daniel,
>
> My guess is that you have a libsword.so in /usr/lib or /usr/lib64 or someplace
> else causing problems.
>
> Troy
>
>
>
> On 03/19/2015 02
015 at 10:28 AM, David "Judah's Shadow" Blue <
yudahssha...@gmx.com> wrote:
> Is one not a symlink to the other?
>
> On March 19, 2015 3:19:40 PM EDT, Daniel Sheffield
> wrote:
>
>> Okay, at first it looked like 'make install' only copied the
>
me know if this behaviour is expected.
On Thu 19Mar15 05:02:33PM, Daniel Sheffield wrote:
> I still seem to be getting the compile error on HEAD.
> I'm linking against the correct headers I'm sure...
> Though there is a chance that I've messed something up because I have it
because your code was compiled against
> > the single non-const method header. Could be wrong, but without more
> > information this is my best guess to help.
> >
> > On March 18, 2015 12:41:21 AM MST, Daniel Sheffield
> > wrote:
> > Hi all,
> >
Hi all,
Getting undefined reference to renderText at compile time since r3331.
I see commit r3332 - perhaps this introduced the change?
using HEAD: my project doesn't compile
r3331: my project compiles.
I'm not sure if this is my bad or if definition of renderText is getting missed
out of
Either way should work. Personally I prefer the members to be pointers. But
perhaps it's just because I'm used to C...
--
In the beginning Kibo created the Internet. Now the Internet was formless,
and empty. Randomness was upon the face of computing, and the Spirit of
ARPA moved upon the face of t
nto VerseKey and iterated over fairly easily,
but knowing whether or not the SWKey index is invariant across api versions
will help me to decide on how I should store references in the db. There may
also be another option that I am not aware of which is better than both of
these methods.
Cheers,
able from the repositories in Fedora, and
> probably on SuSE. Other distros you're going to be on your own, but you
> could derive your build process from one of those two. I maintain a cross
> compile of sword that sits on top of the Fedora mingw toolchain if you want
> to use it.
u will likely find that the .dll is stored in the bin/ folder and not in
> the lib/ folder. This is because Windows needs the dll to be accessible on
> the same path as the executable (that's probably why you had run time
> problems linking against the version from Xiphos).
>
>
; to get
> it to work with Windows. Those are steps 5 and 6 of the tutorial. Also, in
> step 9, you
> need to make sure that the dlls listed are in the same directory as your
> project output
> (or in a lib path)
> Jon
>
> On 12/31/2014 4:04 PM, Daniel Sheffield wrote:
>
>
ly, if you don't want to use flatapi, then you shouldn't
> include that set of files.
> On Dec 31, 2014 6:05 PM, "Daniel Sheffield" wrote:
>
>> Hi Jon,
>>
>> Thanks for that help, I changed icu-sword dir back to icu (it really is
>> the latest
wiki/CSharp_Bindings_on_Windows
> The first section of this tutorial deals with changes needed to get Sword
> 1.7.3 to build
> with VS2013. You can ignore the remainder.
> Be blessed,
> Jon
>
> On 12/30/2014 8:29 PM, Daniel Sheffield wrote:
>
>> Hi all,
>&
am trying to link it with MinGW's g++...
If anyone can help I'd appreciate it!
Daniel Sheffield
Associate Engineer - Software
Level 2, Building A, The Millennium Building Phase 2, 600 Great South Road
Ellerslie,
Auckland,
1051
+64 9 926 2895 Office
+64 21 1408 708 Mobile
http://www.em
13 matches
Mail list logo
