@public: "I have been able to build our large project in BDS 2006 - a debug build, 
after a bit of fiddling. The project combines OWL and VCL.
When I switch to release build, I get a number of strange errors:
The first one is:
[Linker Fatal Error] Fatal: Oject file 
C:\TST\BUILD2006\RETAINCPP_CURRENT\RETAINCPP\RELEASE_BUILD\CBARRAYS.OBJ 
is missing a section of class 0
This doesn't seem to correspond to a source file anywhere, so I assume 
it is an internal file. I can copy the obj file from the debug build but 
obviously that is not a full solution.
There are some further errors I hit which I am still trying to 
understand. These don't appear in the debug build and are several 
thousand of the form:
[Linker Warning] Warning: Public symbol 'void 
OWL888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ReadBaseObject<OWL888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TComboBox>(OWL888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TComboBox *, OWL888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ipstream&)' 
defined in both module 
C:\TST\BUILD2006\RETAINCPP_CURRENT\RETAINCPP\RELEASE_BUILD\GLOBAL1.OBJ 
and 
C:\TST\BUILD2006\RETAINCPP_CURRENT\RETAINCPP\RELEASE_BUILD\TBOOKINENT.OBJ
Thanks for any pointers.
Charles"
    @zxtt: "<quote>
This probably means that a method is implemented in a header file that 
is included by many sources. Maybe inlining options are different in 
debug and release builds or linker warning levels are different."
    @cNO_SPAMpleasefarrell: "Hi,
<quote>
It doesn't sound like part of shipping BDS. Could it be
a helper for OWL? Maybe grep through OWL source for it.
Yes, like Alex sais, the debug switch -vi will inline
inlines and -vi- will out-of-line inlines so suppressing
the linker warning is probably what you want.
Craig"
    @public: "<quote>
I had a look through all the sources OWL and elsewhere, and couldn't 
immediately find anything corresponding.
I thought it might be an internal file with it being named CB.
I will play around with the compiler options.
Charles"
    @public: "<quote>
Turning off inline function expansion removes all the linker warnings 
and errors.
However, despite reporting success and producing a tds file, no 
executable is produced.
The workaround is strange. If I define an OWL Macro PRECONDITION with 
the debug version, then it will produce an exe, however if I leave it 
blank (as it should be in release mode) no executable is produced by the 
linker.
I thought I would have a go at creating a make file to look through the 
command line, but the proj2mak utility produces the error:
OLE error 80131534, ClassID: {F8FEDD39-E3CE-4B8D-A657-9CA24686881F}
I think I have workarounds, but it would be nice if I didn't have to 
fiddle around until I find options which don't have an issue.
Charles"
    @daviddeanno: "<quote>
   This is a known issue. see the workarounds and comments for this 
report:
<<url>
-David Dean
CodeGear C++ QA Engineer"
    @cNO_SPAMpleasefarrell: "Hi,
<quote>
Do you know about "Show Command Line" (Tools | Options
| Compiling). You can then copy and paste the whole command
line from the message window (copy it when the node is collapsed).
Paste into notepad and save with a .bat extension for a quick
command line build. You may have to make minor corrections for
things like line breaks, etc.
Craig"
    @public: "<quote>
I was able to get the command line running. However I get the same 
issue. The linker doesn't report any issues, but no executable is produced.
I have a feeling that it relates to a general issue with inline 
functions, and the debug PRECONDITION macro forces out of line functions 
as it includes a throw statement.
Charles"
    @public: "<quote>
Thanks David, I will yduran@example.org.
Any ideas on the linker issue not producing an exe. As mentioned 
elsewhere, I have a feeling that it relates to a general issue with 
inline functions, and the debug version of the PRECONDITION macro forces 
out of line functions (as it includes a throw statement). It's a bit 
difficult to tell as the linker doesn't issue any error or warning messages.
Charles"
    @daviddeanno: "<quote>
   I was hoping that you might get some information from the linker by 
doing a command line build. The linker doesn't always communicate well 
with the IDE in some error conditions. 8-(
   I assume the project is huge and confidential...
-David Dean
CodeGear C++ QA Engineer"
    @public: "<quote>
If I change the definition of the PRECONDITION macro in checks.h (the 
OWL version), the exe is generated fine. I am fairly sure that it is a 
bug in the linker. Given that I was trying to build a release version, 
ideally I didn't want PRECONDITION defined with the debug code.
Thanks
Charles"
    @public: "<quote>
The command line doesn't return any message unfortunately. I have tried 
with a small demo project, and that works fine. I have spent a 
reasonable time fiddling with the precondition #define, but I seem to 
have to have the bit with "throw precondition" in it for the project to 
build properly.
It is quite a large project. I wouldn't mind sending it on a 
confidential basis as I would like to get some of the irritations on the 
C++ side ironed out, but it includes various 3rd party delphi 
components. I was thinking of running ilink32 through our command line 
debugger (written in Delphi) to see if there were any internal 
exceptions thrown. Is there some logging mode to see where it thinks it 
has got to? I have tried verbose.
Charles"
    @STOPtechiepundit: "<quote>
So then does this break because Borland/CodeGear used .NET to write bdsproj2mak.exe?
If so, I have a basic request to CodeGear: Don't do that!
Avoid use of .NET and write stuff in a native compiled language. That way we do not 
have to wrestle with yet another issue that can make things work on some computers 
but break in some later environment that MS creates after a Borland/CG product gets 
released."
    @VavanRemove: "On Sat, 06 Jan 2007 16:02:49 +0000, Charles Pope
<quote>
try to use ulink instead, perhaps it will report something?
Vladimir Ulchenko aka vavan"
    @VavanRemove: "On Thu, 11 Jan 2007 19:20:47 +0000, Charles Pope
<quote>
then download it from ftp.styx.cabel.net\pub\unilink and put where you
want to see it :)
Vladimir Ulchenko aka vavan"
    @public: "<quote>
Thank you. I hadn't heard of this before. I will give it a go, once I 
have got the command line options worked out.
Charles"
    @VavanRemove: "On Sat, 13 Jan 2007 13:29:00 +0000, Charles Pope
<quote>
you also may want to use bcc32pch addon which allows to use 3rd party
linker easily and produces makefiles to use with command-line tools
much better than native borland's converter
Vladimir Ulchenko aka vavan"
    @public: "<quote>
I have installed this, and am using it with ulink. They work really 
well, and actually resolve the issues I was having. Thank you for 
pointing me to this.
Charles"
    @VavanRemove: "On Mon, 15 Jan 2007 11:56:39 +0000, Charles Pope
<quote>
glad it helped. actually it is the answer I was expecting to hear. you
know ilink is famous for its numerous bugs and inefficiency. you
better stick with ulink which is the best (and universal ie you can
use it with msvc etc.) linker available. combination of bcc32pch and
ulink really brings bcb quite close to the level of delphi
productivity in terms of building speed
Vladimir Ulchenko aka vavan"
    @public: "<quote>
I have hit one issue, which is when doing a debug build it doesn't like 
the debug format in the object files of a couple of the compiled delphi 
pas files, so it doesn't work quite so well when you have pascal source 
in the project.
The release build works fine.
Charles"
    @VavanRemove: "On Mon, 15 Jan 2007 12:48:51 +0000, Charles Pope
<quote>
hmm, interesting. I almost always have several pas-files in my bcb
projects but cannot remember whether I had any troubles debugging
those or not. actually these days I tend not to use bds debugger at
all since it refuses to work most of the time :)
if it is related to ulink (it actually produces tds files _several_
times smaller than ilink32 does) and you can reproduce it please
report back to ulink author, he is very responsive and always fixes
bugs very quickly
Vladimir Ulchenko aka vavan"
    @public: "<quote>
I find the BDS debugger fine, much better than the old versions we were 
using (i.e. BC 5 and Delphi 6). The files which ulink is having problems 
with in debug mode are third party code, so I will see if there is 
anything I can make that is reproducible.
What do you use for debugging?
Charles"
    @VavanRemove: "On Mon, 15 Jan 2007 17:42:29 +0000, Charles Pope
<quote>
good for you. for me using bds debugger almost inevitable leads to
locked ide so I have to kill the process
I think you could send those object and response files (if you cannot
reveal sources) with explanation of problems you have in debug mode
most of the time I'm constrained with my brains combined with logging
statements :)
Vladimir Ulchenko aka vavan"
    @public: "<quote>
I found the problem. At the top of the pascal files I had statements of 
the form:
type  TFormRef = class of TCustomForm;
I don't think TCustomForm existed as a class. However the files did 
compile OK, but these seemed to cause invalid object format.
If I commented out these lines, the linker worked fine. So they were not 
required.
The only other problem was a res file which ulink did not like. I can 
probably send this, as it is included in our exe anyway. BC5 did not 
like this file either, but I rebuilt using one of the free resource 
editors and then it was ok.
Charles"
    @public: "<quote>
I can send an example object file with source which was causing a 
problem, along with a res file I had to rebuild.
I have got over the problems, and ulink is working well.
Thanks
Charles"
    @VavanRemove: "On Thu, 18 Jan 2007 18:08:02 -0800, "David Dean [CodeGear]"
<quote>
David, I hardly believe that codegear will ever be able to vie with
Haron's ulink regarding linker speed and compliance since this is very
specific area requiring lot of expertise
you know better than me that most of the ilink reports in qc closed as
"unable to reproduce", "need more info" etc. and most of the time
someone here had linker troubles one couldn't provide test case, it's
just too cumbersome
at the same time there are many enough (partially thanks to your
efforts) reproducible reports regarding compiler so you guys
definitely have a lot to improve and I'd like codegear to concentrate
their restricted bcb resources and pay attention to compiler mainly
forget about linker, I personally won't ever use ilink32 while there
is ulink available. if I find some bug in it just the other day (or
even several hours later) Yury provides me with new release. not to
mention its blazingly fast linking
I wonder if anyone here believes that codegear will ever start to
release hotfixes and updates at least once a month?
anyway I wish you good luck in improving bcb, I consider an obvious
increasing of open and reported items in cpp compiler area of qc as a
good sign :)
Vladimir Ulchenko aka vavan"
    @VavanRemove: "<quote>
I downloaded build 1.13 on January 15 and can email it to you if you
want
Vladimir Ulchenko aka vavan"
    @bav: "<quote>
Got it, but can't start with last (2.7) Andreas' tool:
UniLink v1.05 [beta] (build 1.13)
Illegal option value: '-l' in response file
Alex."
    @bav: "<quote>
I use BCB5 and Andreas' pch-plugin.
External linker is activated with this plugin.
I see the error message but I can't find any ulink related rsp file on 
my HDD after compilation/linkage ...
Alex."
    @VavanRemove: "<quote>
rsp file has nothing to do with either ulink or ilink32, it is
produced with make and then later linker fed with this response file.
you should export makefile produced with bcc32pch and use the
following in command prompt: make -fYourMakFile -K
then you'll see rsp file
Vladimir Ulchenko aka vavan"
    @daviddeanno: "<quote>
   Thanks. I have high hopes and high expectations. As a user of BCB 
before joining CodeGear, you should find I have a very sympathetic ear. 
The compiler /is/ my priority, but other areas shouldn't be ignored.
-David Dean
CodeGear C++ QA Engineer
<<url>"
    @public: "<quote>
This was actually a ulink issue, but I can send the files to both of you 
should you wish to look.
My main issue with ilink was that it did not produce an executable in 
release mode and it was crashing if I chose to create a map file. There 
was a work around for the first issue. As mentioned earlier on.
Thanks
Charles"
    @bav: "<quote>
In exported pch make file:
LFLAGS = -D"" -aa -Tpe -x -Gn -v -t
-L"$(BCB)\Projects\Lib"; <..snip..> -l
File MAKE0000.@@@:
-D"" -aa -Tpe -x -Gn -v -t
-L"D:\PROGRA~1\Borland\CBUILD~1\Bin\..\Projects\Lib";
"D:\PROGRA~1\Borland\CBUILD~1\Bin\..\lib";
<..snip..>
-l +
c0w32.obj Vcl50.bpi Vclx50.bpi bcbsmp50.bpi Vcldb50.bpi vclado50.bpi
<..snip..>
VCLSMP50.bpi Memmgr.Lib sysinit.obj AH_Test.obj Main.obj, +
E:\User\AlexB\CBuild\AH_TEST\AH_Test.exe,, +
import32.lib cp32mti.lib , +
, +
"AH_Test.res" "Main.dfm"
Ulink hates "-l". If I replace it on "-L" in make file  all goes OK.
And ... what now?
Alex."
    @VavanRemove: "<quote>
well, those are completely different options. perhaps you should read
info.txt from describe.zip and/or ask Yury
Vladimir Ulchenko aka vavan"
    @bav: "<quote>
Unfortunately server rejects mail ...
Mere curiosity: why you have not the same problem with '-l' ?
Alex."
    @VavanRemove: "<quote>
you may want to see "Command Line" from Project Options dialog,
alternatively you could try to use native borland's bdsproj2mak and
another one written by Darko Miletic to get the idea where that option
comes from. in the past bcc32pch had some issues with generating
mak-files but I don't know who to blame this time
Vladimir Ulchenko aka vavan"
    @bav: "<quote>
I use BCB5 now, not BDS. For native IDE compilation:
[Linker Hint] E:\User\AlexB\CBuild\MetrologyStend\MetrologyStend.exe 
-D"" -aa -Tpe -x -v -L..\..\Repository\BCB\GrayBmp;
..\..\Repository\BCB\Threads;
..\..\Repository\USB\VsUsbCam;
..\..\Repository\BCB\Performance;
"d:\program  files\borland\cbuilder5\User Components\JCL\lib\c5";
<snip>
"D:\Program Files\madCollection\madBasic\BCB5\";
"D:\Program Files\madCollection\madDisAsm\BCB5\";
"D:\Program Files\madCollection\madExcept\BCB5\";
"D:\Program Files\madCollection\Plugins\";
"D:\Program Files\madCollection\madExcept\..\Plugins"
No any '-l' as you can see.
Exported native make file:
LFLAGS = -D"" -aa -Tpe -x -v
And no any '-l' in file ... :((
'-l' is mentioned in ulink docs, but I can't find any mention in BCB help.
Alex."
    @VavanRemove: "<quote>
looks like bcc32pch glitch? then you could ask Andreas Hausladen where
that comes from
according to bds2006 help -l "tells the linker to place bpi/lib output
files in the directory specified". according to ulink help using of -l
option mainly supposed to be used in gcc mode and not recommended for
borland targets
Vladimir Ulchenko aka vavan"
    @bav: "<quote>
I've got the same answer form Andreas, thanks.
-l has 2 meanings. The second is (see info.txt in Russian):
    -l - для совместимости с make/rsp-файлами, автосгенерёнными 
борландом. Позволяет задавать путь, для генерируемого implib'а.
ВНИМАНИЕ: В новых файла рекомендуется использовать -GI, чтобы снизить
путаницу с работой в gcc-режиме.
Probably ULink wrongly treats -l option as error if path is empty. Can 
you ask Yury about it? (his server rejects my e-mails).
In any case now ULink is happy, after I have entered '.' as BPI/LIB 
path. :)
Thank you for help.
Alex."
    @VavanRemove: "<quote>
I wonder why -I appeared in generated mak-file if you didn't activated
that option in your project?
sounds reasonable. why to use the key if you omitted the path?
what email did you try?
Vladimir Ulchenko aka vavan"
    @bav: "<quote>
The same question I've asked in Andreas' forum. :)
It's true, but IMHO empty path isn't a crime ...
<email_address> (for new ver notification).
Mail Delivery System <email_address>
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
   <email_address>
     SMTP error from remote mailer after MAIL FROM:<email_address> 
SIZE=1867:
     host gsh.styx.cabel.net [83.161.120.155]: 550 5.7.1 
<email_address>... MX 10 'mxs.mail.ru.' [83.161.120.155] for
<email_address> rejected address saying "Access from ip address 
83.161.120.155 blocked.
I yet did not try <email_address>
After all I have the problem with linkage.
BCB5, ulink.cfg file options: -F -Ge
UniLink v1.05 [beta] (build 1.13)
Error: Attempt to redefine import for symbol 
'@$xp$20Controls@TAnchorKind' in
'D:\Program Files\Borland\CBuilder5\lib\release\Vcl50.bpi|Controls'
Warning: Export (or def-file import) symbol 
'`__DPdsc__'[Controls888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TAnchorKind]' overload BPI-style import from 
'D:\Program Files\Borland\CBuilder5\lib\release\Vcl50.bpi|Controls'
Error: Attempt to redefine import for symbol 
'@$xp$20Controls@TAnchorKind' in
'D:\Program Files\Borland\CBuilder5\lib\bcbsmp50.bpi|Ccalendr'
Warning: Export (or def-file import) symbol 
'`__DPdsc__'[Controls888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TAnchorKind]' overload BPI-style import from 
'D:\Program Files\Borland\CBuilder5\lib\bcbsmp50.bpi|Ccalendr'
I've found a mention of this problem in the linker doc, but I don't know 
what to do further.
Alex."
    @VavanRemove: "<quote>
above is correct address to ask your questions and/or send bug-reports
please see beta.txt (section Bug-reports)
Vladimir Ulchenko aka vavan"
{'source': 'USENET', 'other_information': '{"reply_count": 41, "forum_name": "borland.public.cppbuilder.non-technical.20141104.mbox"}', 'file': 'data/output/usenet-borland.public.parquet'}