fba fabio

Opa, que bom, então já foi corrigido

Perceba que o {$IFNDEF MSWINDOWS} esta dentro do bloco {$ELSE} do {$IFDEF MSWINDOWS} ou seja, ele nunca irá entrar no {$ELSE} do {$IFNDEF MSWINDOWS} e sempre retornará 'libxmlsec1' sendo que o correto seria retornar 'libxmlsec.so' ou 'libxmlsec1.so', ele não deveria retornar somente o nome da lib sem o '.so' {$IFDEF MSWINDOWS} {$IFDEF USE_MINGW} LIBXMLSEC_SO = 'libxmlsec1.dll'; {$ELSE} LIBXMLSEC_SO = 'libxmlsec.dll'; {$ENDIF} {$ELSE} LIBXMLSEC_SO = {$IFNDEF MSWINDOWS}'libxmlsec1'{$ELSE}'libxmlsec.so'{$ENDIF}; {$ENDIF}

Fiz alguns testes (Fedora 28) e as libs estão dispostas da seguinte forma: ls -sal /usr/lib64/libssl* /usr/lib64/libssl3.so /usr/lib64/libssl.so -> libssl.so.1.1.0i /usr/lib64/libssl.so.10 -> libssl.so.1.0.2o /usr/lib64/libssl.so.1.0.2o /usr/lib64/libssl.so.1.1 -> libssl.so.1.1.0i /usr/lib64/libssl.so.1.1.0i ls -sal /usr/lib64/libcrypto* /usr/lib64/libcrypto.so -> libcrypto.so.1.1.0i /usr/lib64/libcrypto.so.10 -> libcrypto.so.1.0.2o /usr/lib64/libcrypto.so.1.0.2o /usr/lib64/libcrypto.so.1.1 -> libcrypto.so.1.1.0i /usr/lib64/libcrypto.so.1.1.0i A função LoadLibHack que é responsável por encontrar as libs, procura primeiro pela lib sem versão nenhuma, então bastou ajustar para que ele procure primeiro pelo '.10' para que fosse realizado o carregamento da lib correta OpenSSLExt DE: DLLVersions: array[1..16] of string = ('', '.1.0.6', '.1.0.5', '.1.0.4', '.1.0.3', '.1.0.2', '.1.0.1','.1.0.0','.0.9.8', '.0.9.7', '.0.9.6', '.0.9.5', '.0.9.4', '.0.9.3', '.0.9.2', '.0.9.1'); PARA: DLLVersions: array[1..17] of string = ('.10','', '.1.0.6', '.1.0.5', '.1.0.4', '.1.0.3', '.1.0.2', '.1.0.1','.1.0.0','.0.9.8', '.0.9.7', '.0.9.6', '.0.9.5', '.0.9.4', '.0.9.3', '.0.9.2', '.0.9.1'); Usando a lib da série 1.0 a assinatura ocorreu corretamente tanto usando xsLibXml2 como xsXmlSec e a conexão com o webservice também funcionou normalmente Fiz alguns testes em C com as duas versões da lib série 1.0.2 e 1.1.0 para o método EVP_DigestInit, que é onde esta ocorrendo o erro usando a versão 1.1 da lib ao tentar assinar usando xsLibXml2. Foi preciso fazer várias pequenas modificações no código em C para funcionar na versão nova. Atualmente estou usando a versão 1.1 da lib OpenSSL para emissão de NFe e esta rodando corretamente, as exceções ficam por conta da xsLibXml2 que pode ser substituída pela xsXmlSec e o bug do tópico em questão no método GetNotAfter, verificando no site https://www.openssl.org/source/ o suporte a versão da série 1.0.2 (LTS) terminará em 31/12/2019 e eles recomendam que todos migrem para a próxima versão LTS 1.1.1 que tem suporte até setembro de 2023

Encontrei o problema, esta na propriedade AutoSize ao selecionar bcCode128C e incluir um código de barras com 44 caracteres ele esta definindo o Width para 286 porém desmarcando a opção AutoSize e definindo manualmente o Width para 289 a renderização ocorre corretamente

Vou reportar o erro no projeto Fortes Report CE, as vezes algum pequeno ajuste resolva o problema, mas de imediato acredito que incluindo uma diretiva para alterar o tipo de código de barras de bcCode128C para bcEAN128C quando a compilação for realizada no Linux resolva o problema

O PDF sai com o código exatamente da mesma forma que o gerado no form, acredito que o que vai para o PDF seja exatamente o mesmo bitmap gerado pelo componente de códigos de barras no form

Ola, você tem razão, ao usar xsLibXml2 quando tenta gerar a NFe ocorre 'ERRO: Access violation', usando a configuração conforme imagem anexa tudo funciona normalmente Vou dar uma olhada no código em relação ao uso da xsLibXml2, as vezes com alguns ajustes seja possível rodar no Linux com a Openssl 1.1

A alteração realizada no arquivo Fontes/ACBrOpenSSL/libxmlsec.pas Alterada a linha: LIBXMLSEC_SO = 'libxmlsec.so'; para: LIBXMLSEC_SO = {$IFNDEF MSWINDOWS}'libxmlsec1'{$ELSE}'libxmlsec.so'{$ENDIF}; Esta alteração esta gerando o erro abaixo ao tentar gerar/assinar o xml da NFe: ERRO: "xmlSecNodeSignature" could not be loaded from the dynamic library libxmlsec1 Uma solução paliativa para contornar o problema foi criar um link simbólico com o nome libxmlsec1 sem a extensão .so ln -s /usr/lib64/libxmlsec1.so.1 /usr/lib64/libxmlsec1 https://github.com/GabrielF7/ACBrTrunk2/commit/c49df5f71c32474ae5caa9b5b32e4485eca5ba5a#diff-315e5578b57ec7910d57ff00a15b02c2

No Ubuntu após vários testes o que funcionou foi baixar e compilando diretamente do repositório o xmlsec1, no Fedora bastou instalar os pacotes diretamente dos repositórios e criar um link simbólico pois ao realizar o build do Lazarus ele não estava encontrando a lib xmlsec1, abaixo segue o passo a passo que utilizei baseado nas dicas do vídeo https://www.youtube.com/watch?v=wU8KRNMwUaw #UBUNTU 18.04 apt install libxml2-dev apt install libltdl-dev apt install libssl-dev wget http://www.aleksey.com/xmlsec/download/xmlsec1-1.2.27.tar.gz tar -zxvf xmlsec1-1.2.27.tar.gz cd xmlsec1-1.2.27 ./configure make make install #FEDORA 27/28 yum install libxml2-devel yum install libxslt-devel yum install libtool-ltdl-devel yum install openssl-devel yum install xmlsec1 ln -s /usr/lib64/libxmlsec1.so.1 /usr/lib64/libxmlsec1.so

Acredito que não tenha relação com o Filtro para PDF, pois olhando o código fonte do fortes é possível verificar que é feita a instanciação de um objeto canvas que gera um bitmap como saída, e o erro ocorre durante a manipulação do componente ao ser inserido diretamente em um form como pode ser visto na imagem que postei

O único problema relacionado ao OpenSSL até o momento foi no método GetNotAfter Estou usando o ACBrMonitor PLUS para emissão de NFE rodando no Ubuntu 18.04 Compilado com Lazarus 1.8.0 2018-03-17 FPC 3.0.2 no Fedora

Realizei novos testes e verifiquei que o problema ocorre devido a variação na quantidade de caracteres conforme pode ser visto na imagem em anexo. O fato de funcionar usando o bcEAN128C com Ratio 2 se deve realmente ao fato da inclusão do dígito verificador fazendo com que o código resultante fique em 46 caracteres, aparentemente o problema esta no fortesreport-ce

Ola,você tem razão, baixei somente a cópia do relatório para ter a versão mais atualizada e não atualizei o projeto todo

Este problema aparentemente tem relação com a versão do OpenSSL (estou usando OpenSSL 1.1.0i-fips 14 Aug 2018), acredito que o método da lib openssl que retorna a data de validade do certificado foi modificado e esta retornando nil, uma solução temporária que encontrei para bypass o problema foi o seguinte: Alterar o método ./Fontes/ACBrDFe/ACBrDFeOpenSSL.pas linha 136 function GetNotAfter( cert: pX509 ): TDateTime; var Validade: String; notAfter: PASN1_TIME; begin // *** remover as linhas comentadas abaixo: *** // notAfter := cert^.cert_info^.validity^.notAfter; // Validade := {$IFDEF DELPHIXE4_UP}AnsiStrings.{$ENDIF}StrPas( PAnsiChar(notAfter^.data) ); // SetLength(Validade, notAfter^.length); // Validade := OnlyNumber(Validade); // if notAfter^.asn1_type = V_ASN1_UTCTIME then // anos com 2 dígitos // Validade := LeftStr(IntToStrZero(YearOf(Now),4),2) + Validade; // Result := StoD(Validade);} // *** adicionar apenas o Result abaixo que equivale retornar como data de validade a data 22/02/2022 *** Result := StoD('20220222000000'); end; Após a alteração abrir ./Pacotes/Lazarus/ACBrDFe/ACBrDFeComum.lpk e compilar novamente

Removi uma linha do código referente a logo que estava dando erro ao compilar ./Fontes/ACBrDFe/ACBrNFe/DANFE/NFe/Fortes ACBrNFeDANFeRLRetrato.dfm ACBrNFeDANFeRLRetrato.lfm ACBrNFeDANFeRLRetrato.pas

Modifiquei as seguintes propriedade do componente de código de barras: Alignment: taLeftJustify BarcodeType: bcEAN128C Caption: 12345678901234567890123456789012345678901234 Fiz testes de leitura do código de barras usando o app https://play.google.com/store/apps/details?id=com.google.zxing.client.android e leu o código corretamente, Formato: CODE_128, Tipo: TEXT