Assertion failed file /Users/joe/mclinker ?

Hi,
I am using 2018 release 1.1, worked fine for some time, today trying to compile a 32bit ARM exe, I get this -

Linking Executable
Assertion failed: (related->flag() & llvm::elf::SHF_GROUP), function readSections, file /Users/joe/mclinker/lib/LD/ELFObjectReader.cpp, line 150.

I don’t have a user/joe ?
Any ideas?

That error path is from Joe’s system.

Have you made sure that the “Builds -” folder is empty?

It’s funny when information from one person’s build system leaks like this - I once had a coworker who named his hard drive “Sh*tHead” which occasionally led to some interesting bug reports :slight_smile:

That looks like something from “mclinker”. See https://github.com/mclinker/mclinker .

The Valentina folks use something called “Jenkins”. I thought for years that this was a name.

Could it be @Joe Ranieri?

Have you tried all three compiler optimization levels?

Do you get this compile error on an empty project?

It very probably is. But he was not seen here for over a year, so I guess he will not answer.

Joe originally compiled the linked on his workstation that’s where that comes from.

Ok, instead of double clicking the ide to start it, open a terminal window, type open , drop the Xojo.app bundle into the terminal window and press return. The ide will launch and spew a bunch of console messages. Once the ide launches, go to the terminal window and press CMD-K to clear the window. Now create a web project and compile it for Linux ARM. I’m curious if you get any errors there.

What plugins have you got installed and is this app trying to use any of them? Maybe they have no ARM 32 bit portions?

Firts clear the xojo cache, in preferences - builds. Then quit xojo completely. remove the plugins, re-download and reinstall them in the plugins folder.open xojo again.

Then make sure to select “ARM 32” for linux builds.

I’ve been corresponding with Dave via email, and apparently this issue is with the Chilkat module built for ARM 32. I don’t know the solution, but maybe if Xojo and Chilkat share notes about LLVM compiler/linker versions and options, we might sort it out.

In other words, I’m going to show the compile and link options Chilkat uses to build the shared lib, and maybe Xojo can share the same for how a Xojo application is built. If both are the same, then one would think there would be no trouble when the .exe tries to load the shared lib…

Chilkat compiles its sources (for Xojo ARM 32) like this:

clang+±7 -I …/ChilkatLib/Package/include -I …/XojoPlugin/src/xojo2015r4/Includes -I…/support -D__linux__ -DIGNOREQT -D__INTEL__ -DLINUX=1 -D__GCC__ -DTARGET_64BIT=0 -DARMV7_LINUX -DCK_ARM -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DCK_LINUX -DCK_CLANG -fPIC -O2 -c -fmessage-length=0 -fno-stack-protector -g0 -fvisibility=hidden -fvisibility-inlines-hidden -Wno-expansion-to-defined -o ZipEntry.o …/XojoPlugin/src/chilkat/ZipEntry.cpp

Chilkat links for Xojo ARM 32 ( to produce the shared lib) like this:

/usr/lib/llvm-7/bin/ld.lld -r -s -o"/home/chilkat/workspace/chilkat/lib-xojo/libchilkatXojo.so" PluginMain_modified.o Asn.o Atom.o AuthAws.o AuthAzureAD.o AuthAzureSAS.o AuthAzureStorage.o AuthGoogle.o AuthUtil.o BinData.o Bounce.o Bz2.o Cache.o Cert.o CertChain.o CertStore.o Charset.o CkDateTime.o Compression.o Crypt2.o Csr.o Csv.o Dh.o DirTree.o Dkim.o Dsa.o DtObj.o Ecc.o Email.o EmailBundle.o FileAccess.o Ftp2.o Global.o Gzip.o Hashtable.o HtmlToText.o HtmlToXml.o Http.o HttpRequest.o HttpResponse.o Imap.o JavaKeyStore.o JsonArray.o JsonObject.o Jwe.o Jws.o Jwt.o Log.o Mailboxes.o MailMan.o main.o MessageSet.o Mht.o Mime.o Ntlm.o OAuth1.o OAuth2.o Pem.o Pfx.o PrivateKey.o Prng.o PublicKey.o Rest.o Rsa.o Rss.o Scp.o SecureString.o ServerSentEvent.o SFtp.o SFtpDir.o SFtpFile.o Socket.o Spider.o Ssh.o SshKey.o SshTunnel.o Stream.o StringArray.o StringBuilder.o StringTable.o Tar.o Task.o TaskChain.o TrustedRoots.o UnixCompress.o Upload.o Url.o WebSocket.o Xml.o XmlCertVault.o XmlDSig.o XmlDSigGen.o Xmp.o Zip.o ZipCrc.o ZipEntry.o …/lib-clang/libchilkat-9.5.0.a

(The sources in the libchilkat-9.5.0.a were compiled in the same way.)

prior to Dave’s first problem report, Chilkat was using clang++6.0 like this:

clang+±6.0 --target=arm-linux-gnueabihf --gcc-toolchain=/usr/lib/gcc/arm-linux-gnueabihf/7.3.0 INCLUDE_DIRS -DARMV7_LINUX -DCK_ARM -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DCK_LINUX -DCK_CLANG -fPIC -I /usr/include/arm-linux-gnueabihf/c++/7 -I /usr/include/c++/7 -O2 -c -fmessage-length=0 -fno-stack-protector -g0 -fvisibility=hidden -fvisibility-inlines-hidden -Wno-expansion-to-defined OBJFILE SRCFILE

and linking like this:

clang+±6.0 --gcc-toolchain=/usr/lib/gcc/arm-linux-gnueabihf/7.3.0 -g0 -L"/usr/lib/gcc/arm-linux-gnueabihf/7.3.0" -L"…/lib-armv7l_static" *.o -o"UnitTest" -lchilkat-CHILKAT_VERSION -lpthread -lresolv